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ABSTRACT 


When called upon, the Department of Defense (DoD) typically organizes and 
integrates mission capabilities from across the enterprise, operates as a joint force, 
disassembles when the mission is complete, and prepares for the next potential mission. 
This dissertation presents an organizing construct and associative mapping tool that 
enables the systems engineering of this episodic joint operational mission capability. The 
Operational Mission Architecture Framework (OMAF) organizes the key elements of 
joint operational capability into an intuitive framework, orienting systems engineers to 
this critical perspective. With operational mission capability now in architecture form, 
enterprise architecture methodologies can then be applied directly to operational 
missions. The Operational Blended Architecture Map (OBAM) serves as the integrating 
mechanism. This blended approach allows the operational community to communicate in 
its own terminology with systems engineers, who, in turn, can execute 
enterprise-architecting activities in their own terminology, facilitated by this associative 
mapping matrix. OMAF/OBAM enables the desired top-down systems engineering effort 
for joint operational capability and Systems of Systems development. The cumulative 
effect of OMAF/OBAM provides the integrating function for a DoD capability 
development enterprise architecture. Without an enterprise approach, the DoD will 
continue to be challenged to deliver 21st century joint warfighting capability. 
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EXECUTIVE SUMMARY 


Benjamin Franklin, speaking at the Philadelphia convention in September 1787, 

stated, 

for when you assemble a number of men to have the advantage of their joint 

wisdom, you inevitably assemble with those men all their prejudices, their 

passions, their errors of opinion, their local interests, and their selfish views. 

From such an assembly can a perfect production be expected? 

Our nation deploys, and continues to deploy, forces to operate around the world as 
part of a combined force conducting operations across multiple warfighting domains 
simultaneously. These forces are typically reactive and composed of multiple, disparate 
enterprises (Services, agencies, partner nations, non-governmental organizations, private 
industry) that are tailored to meet projected mission requirements. Contributing 
organizations bring elements of their organic capabilities and systems, manpower, and 
culture, which are then assembled into a “joint” capability that operates as a doctrinal joint 
force, disassembles when the mission is complete, and prepares for the next potential 
mission. This “episodic” Department of Defense (DoD) enterprise capability is developed 
and maintained (preparedness and readiness) through “a knowledge-based integrated 
enterprise” approach, executed under the Chairman of the Joint Chiefs of Staff (CJCS) 
Joint Force Development (JFD) Life Cycle (CJCS 2013). 

The JFD system as a whole, which “delivers” the DoD knowledge-based 
component of our nation’s joint warfighting capability, is not integrated with the materiel 
development systems. Joint operations are not systems engineered, but rather assembled 
from existing Service capabilities. Although our nation cannot wait for systems engineers 
to gain joint experience, or for joint commanders and staff members to become systems 
engineers, or for the DoD enterprise to modify its capability development systems, we can 
find common ground. 

The DoD Defense Acquisition System (DAS), the Joint Capability Integration and 
Development System (JCIDS), and DoD Architecture Framework (DODAF) all support 
the development of integrated architectures. Those processes deliver physical systems but 
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are not designed to provide traceability to the operational capability delivered by those 
systems. Given the specific intended applications of those processes, it is not possible to 
ensure that a system developed in compliance with those processes will meet the needs of 
the actual stakeholder when the system of interest is an episodic enterprise system (the 
operational mission commander in charge of accomplishing a military objective utilizing 
episodic, enterprise systems). This dissertation delivers common ground for capability 
development through a joint operational architecture framework construct, tailored to the 
unique challenges of the episodic nature of these enterprise operational capabilities and 
systems that leverage the value DoD already places on integrated architectures. 

There are unique challenges associated with episodic operational systems (beyond 
traditional systems employed for joint operations). Specifically, we know we are never 
going to have to solve the exact same problem twice, but we also know that we are going 
to have to solve many similar problems using the same systems. Therefore, we need an 
approach for doing so. This dissertation presents an organizing construct and associative 
mapping tool that enables the systems engineering of this episodic joint operational mission 
capability (or episodic enterprise systems). This new class of episodic systems is 
characterized by their temporal, transitional, asynchronous, and multi-mission attributes 
that drive design. 

Deployed system capabilities are defined, managed, engineered, developed, and 
tested to system requirements and subsequently arranged, tested, and sustained to deliver 
capability that meets validated requirements. Often these requirements are too broadly 
defined to deliver the mission-specific, episodic, warfighting capability necessary to gain 
and sustain an advantage in the complex 21st century operational environment. This 
research seeks to address this disconnect at the architectural level by: 

1. Formalizing the meaning of “operational level capability” through an 
organizing construct. 

2. Defining an architectural framework that can be applied to a broad range 
of enterprise capabilities, rather than specific physical systems or specific 
operational situations. 
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Defining an enterprise architecting associative map. 


4. Providing an integrating function to create a DoD capability development 
enterprise architecture. 

The Operational Mission Architecture Framework (OMAF) organizes the key 
elements of joint operational capability into an intuitive framework, orienting systems 
engineers to this critical perspective. With operational mission capability now in 
architecture form, enterprise architecture methodologies can then be applied directly to 
operational missions. The organizing construct and design of OMAF is not intended to 
replace any or all of the DoD capability develop systems, but rather to integrate them and 
enable the systems engineering of the ten Operational Elements of joint warfighting 
capability. 

The Operational Blended Architecture Map (OBAM) serves as the integrating 
mechanism. OB AM has been developed to enable the use of DoD’s enterprise architecture 
model (DODAF). This blended approach allows the operational community to 
communicate in their own terminology with systems engineers, who in turn, can execute 
enterprise-architecting activities in their own terminology, facilitated by this associative 
mapping matrix. Since joint operational capability is supported by systems and Systems of 
Systems (SoS) architectures developed under the JCIDS and DAS, the application of 
existing enterprise architecture tools and processes promotes an inclusive and efficient 
enterprise approach. OMAF/OBAM enables the desired top-down systems engineering 
effort for joint operational capability and SoS development. 

The cumulative effect of OMAF/OBAM also provides the integrating function for 
a DoD capability development Enterprise Architecture. Without an enterprise approach, 
DoD will continue to be challenged to deliver 21st century joint warfighting capability. 

Through integration of the JFD, DAS, and JCIDS processes it is possible to identify 
the physical systems (and the integration requirements associated with the utilization of 
those systems) required to deliver a specific, enterprise operational level capability and 
repeat that process episodically for a broad range of operational applications. The central 

idea is to organize the guiding principles, operational context, and warfighting systems for 
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joint operations into a visual reference architecture framework that enables the 
development of episodic enterprise systems and integrates DoD capability development 
systems. 

All three systems/cultures/communities are represented in the framework; JFD 
joint context and knowledge-based decision making elements; DAS materiel/system 
capabilities; and, JCIDS operational architectures. This blended approach provides joint 
operational level context for both traditional program/project systems engineering 
activities, and for the application of DoD systems engineering methodologies directly at 
the joint operational level (episodic operational capability). The OMAF is intended to 
leverage the diversity of thought, multi-cultural perspectives, and existing capabilities of 
the DoD enterprise (and cooperating partner enterprises), rather than provide a new, or yet 
another, capability development system. 

The OMAF enables operational mission stakeholders, participants, and capability 
providers to attain unity of effort (CJCS 2017,1-9) for realizing operational level mission 
capability. A DoD enterprise architecture for developing joint warfighting capability 
emerges from the integrating function of OMAF. The integration of these systems at the 
architectural level is minimally disruptive to the enterprise, as existing 
authorities/processes remain in place. 

Beyond the DoD, the notion of episodic capability applies to all enterprises. An 
ability to address unique challenges utilizing existing enterprise systems, processes, and 
relationships to achieve desired outcomes extends to all enterprises seeking to remain 
relevant in a rapidly changing 21st century technology landscape. 
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I. INTRODUCTION 


A. SUMMARY OF PROBLEM AND OVERALL CONTRIBUTION 

The commercial sector has a history of recognizing and responding to 
environmental indicators and delivering new capability (i.e., six generations of I-phones in 
less than ten years). Technological advancements (e.g., advanced computing, big data, 
artificial intelligence, autonomy, robotics, miniaturization, additive manufacturing, meta¬ 
materials, directed energy, and hypersonics), primarily in response to societal desires and 
realized through commercial research and development, have resulted in unprecedented 
operational environment complexity for our warfighters (CJCS 2016). 

The Department of Defense (DoD) typically organizes and assembles/integrates 
mission capabilities from across the enterprise, operates as a joint force, disassembles when 
the mission is complete, and prepares for the next potential mission. Our nation deploys 
forces to operate around the world as part of a combined/partnered force conducting 
operations across multiple warfighting domains simultaneously. 

This is an extremely difficult and complex undertaking, and results in the joint force 
continuing to encounter operational mission capability issues, across a variety of missions. 
These combined/partnered forces are typically defensive and composed of multiple, 
disparate enterprises (Services, agencies, partner nations, non-governmental organizations, 
private industry), intended to meet projected mission requirements. Contributing 
organizations bring elements of their organic capabilities and systems, manpower, and 
culture which are assembled into a “combined” or into a “Joint” operational capability. 
Combined forces include U.S. and partner nation militaries. Joint is a general term applied 
to a force “composed of elements from two or more Military Departments operating under 
a single joint force commander.” (CJCS 2013,1-16). Furthermore, “Jointness implies cross- 
Service combination wherein the capability of the joint force is understood to be 
synergistic, with the sum greater than its parts (the capability of individual components)” 
(CJCS 2013,1-2). 
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This dissertation presents an organizing construct and associative mapping tool that 
enables the systems engineering of this episodic joint operational mission capability (or 
episodic enterprise systems). This new class of systems is characterized by their temporal, 
transitional, asynchronous, and multi-mission attributes that drive design. The Operational 
Mission Architecture Framework (OMAF) organizes the key elements of joint operational 
capability into an intuitive framework, orienting systems engineers to this critical 
perspective. With operational mission capability now in architecture form, enterprise 
architecture methodologies can then be applied directly to operational missions. 

The Operational Blended Architecture Map (OBAM) serves as the integrating 
mechanism. This blended approach allows the operational community to communicate in 
their own terminology with systems engineers, who in turn, can execute enterprise- 
architecting activities in their own terminology, facilitated by this associative mapping 
matrix. OMAF/OBAM enables the desired top-down systems engineering effort for joint 
operational capability and Systems of Systems (SoS) development. 

The cumulative effect of OMAF/OBAM also provides the integrating function for 
a DoD capability development Enterprise Architecture. Without an enterprise approach, 
DoD will continue to be challenged to deliver 21st century joint warfighting capability. 

B. MOTIVATION AND BACKGROUND 

There are similarities in the core tenets of joint force capability (sum greater than 
its parts) and systems engineering architectures that can be associated with realizing joint 
operational capability. However, systems engineering approaches and/or methodologies 
are not being directly applied to achieve. 

The DoD enterprise utili z es a requirements oversight system, an acquisition system, 
and a knowledge-based development system to develop and employ global joint capability. 
The requirements oversight and acquisition systems are integrated at the architectural level 
through an authoritative enterprise architecting methodology focused on developing 
system(s) based capabilities. The knowledge-based development system focuses on the 
cognitive capability necessary for conducting joint operations/missions. Once the specified 
mission is complete, those participating elements of the DoD enterprise return to a 
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readiness state within the knowledge-based capability development system and prepare for 
a future joint operation/mission. Although some products of the knowledge-based 
development system are used to inform the other two capability development systems, it is 
not integrated with them. Additionally, the DoD executes a variety of missions when called 
upon, which are not synchronized with system(s) based capability development and 
fielding schedules (Figure 1). Evolving social norms, adaptive adversaries, and the 
complex, uncertain, and rapidly changing 21st century operational environment challenge 
this approach to fielding joint operational mission capability. 
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Figure 1. DoD Joint Operational Mission Capability. Adapted from CJCS (2013); 

CJCS (2017); SECDEF (2003). 


Currently, the integration necessary to execute assigned joint operational missions 
is performed with knowledge-based guidance, acquired through a formal Joint Force 
Development (JFD) construct (CJCS 2013). Joint operational mission capability is 

therefore an extension of acquired knowledge, rather than being deliberately engineered 
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and developed. This doctrinal (or ideological) influence on operational effectiveness and 
the systems engineering influence on materiel capability development are not deliberately 
aligned, resulting in architectural (structural, functional, organizational, information, 
process) points of contention and incompleteness. 

A well-known example of this operational issue was the inability to network 
combined force IT systems among coalition forces in Operation Enduring Freedom (OEF), 
which commenced in October 2001. The solution, the Afghan Mission Network (AMN), 
finally reached Initial Operational Capability (IOC) in 2010. Work continues today (16 
years after OEF commencement) by the combined forces community, informed by AMN, 
to implement an enduring framework to achieve networked operational level capability. 
This involves coalition partners under the U.S. Mission Partner Environment (MPE) and 
NATO Federated Mission Network (FMN) efforts, and is being implemented through the 
Joint Force Development Life Cycle. 

Systems engineers capture operator’s requirements primarily through the 
development of a Concept of Operations (CONOP) accompanied by architectural 
Operational Viewpoints (OV). The essence of these CONOPs and OVs, however, reside at 
the tactical level of warfare vice the operational level resulting in significant capabilities 
gaps. 

The operational level of warfare links the tactical employment of forces to 
national and military strategic objectives. The focus at this level is on the 
planning and execution of operations using operational art: the cognitive 
approach by commanders and staffs—supported by their skill, knowledge, 
and experience—to develop strategies, campaigns, and operations to 
organize and employ military forces by integrating ends, ways, and means. 

(CJCS 2017, xii) 

Achieving operational mission capability is therefore a human centric 
(commanders and staffs) methodology with dependencies on other human centric activities 
(e.g.. Doctrine community; Service and Joint trainers; Service and Joint exercises; Service 
and Joint lessons learned communities; partners), complex socio-technical systems (e.g., 
command posts). 
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When called upon, the DoD typically organizes and assembles/integrates mission 
capabilities from across the enterprise (i.e., Services), operates as a doctrinal joint force, 
disassembles when the mission is complete, and prepares for the next potential mission. 
This “episodic” DoD enterprise capability is developed and maintained (preparedness and 
readiness) through “a knowledge based integrated enterprise” approach, executed under 
the Joint Force Development Life Cycle (CJCS 2013). 

The DoD enterprise’s ability to produce operational capability requires 
contributions from all three of its capability development systems. Current Enterprise 
Systems Engineering (ESE) and Systems of Systems Engineering (SoSE) approaches 
include architecture, requirements, organization, information, data, and process elements 
across the life cycle of a systems engineering effort. However, where episodic enterprise 
capability, and ultimately operational mission success, is dependent on both knowledge- 
based and SoS capabilities, current DoD systems engineering methodologies fail to 
adequately address the knowledge-based component of operational capability. 

C. PROBLEM DEFINITION AND RESEARCH OBJECTIVES 

This research is focused on the definition of an operational framework to enable the 
development and assessment of episodic enterprise systems. Specifically, this research will 
provide an integrating mechanism linking knowledge-based processes for realization of 
operational capability and requirements-based processes for the acquisition of engineered 
systems. Accordingly, the following research objectives are presented: 

1. Definition of the unique challenges associated with the realization of 
episodic enterprise systems, with particular focus given to the challenges 
associated with the definition of such systems in a Joint Department of 
Defense environment. 

2. Definition of an operational architecture framework uniquely suited to the 
development of episodic enterprise systems. 
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3. Definition of an architecture map that establishes a mapping between the 
operational architecture framework produced in satisfaction of research 
objective #2 and existing systems architecture frameworks. 

D. RESEARCH APPROACH 

This research utilizes the design method as defined in (Giachetti 2016). 
Specifically, this dissertation will develop a new systems engineering process for the 
definition and development of episodic enterprise systems. Accordingly, this dissertation 
is organized into three primary sections: a literature review that summarizes the motivation 
for the research as well as existing engineering processes; a presentation of the proposed 
operational architecture framework and blended architecture map; and a review of 
historical operations to demonstrate the utility of the proposed operational architecture 
framework and blended architecture map. 

E. KNOWLEDGE-BASED ENTERPRISE CAPABILITY 

JFD is a knowledge-based enterprise approach to developing the capability for 
planning and executing assigned joint operational missions. (CJCS 2013). The focus of the 
enterprise is on mission “planning and execution using Operational Art: the cognitive 
approach by commanders and staffs” (CJCS 2013,1-8). Joint concepts, joint doctrine, joint 
education, joint training, joint exercises, and assessments/lessons learned are the primary 
elements of the Joint Force Development (JFD) Life Cycle (Figure 2). JFD does not include 
materiel development, fielding, and sustainment, which are the responsibility of the 
participating organizations (CJCS 2013). Joint operational mission capability is achieved 
through the cumulative efforts of joint force development activities and the deployment of 
materiel from participating organizations in doctrinal compliance with joint operations. 
“The purpose of joint doctrine is to enhance the operational effectiveness of joint forces by 
providing fundamental principles that guide the employment of U.S. military forces toward 
a common objective” (CJCS 2013,1-1). 
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Figure 2. Joint Force Development Life Cycle. Source: CJCS (2013). 

As previously discussed, this knowledge-based enterprise capability is commander 
centric and is intended to “organize and employ forces by integrating ends, ways, and 
means.” (CJCS 2017,1-14). Acquiring the necessary cognitive ability is then dependent on 
the skills, knowledge, and experience of commanders and staffs, obtained through both 
Service and Joint education, assignments, training, and experience. Furthermore, the 
resultant cognition-based capability is sensitive to the introduction of new system(s) based 
capabilities. 

Traditional systems engineering in the Department of Defense is a foundational 
element of systems, SoS, and enterprise systems capability development and is codified in 
DoD policy and instruction. Essentially, the warfighter gets the benefit of the engineering 
mindset as part of an acquisition program or system design/upgrade, both of which rely on 
requirements maturity and clarity. The introduction of these systems into the joint force 
must be institutionalized before operational benefits can by realized. By organizing the key 
operational level elements into an architectural framework and providing an associative 
mapping tool for enterprise architecting, systems engineers may better comprehend and 
account for this cognition-based level of war, and subsequently better support the 
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operational force by applying systems engineering methodologies in the development of 
warfighting systems. 

F. EPISODIC ENTERPRISE SYSTEMS ENGINEERING 

As previously discussed, the DoD enterprise executes a variety of missions as a 
joint force when called upon, then returns to state of readiness and prepares for the next 
potential mission. The necessary joint warfighting capability, including the readiness to 
respond to mission assignments, is developed through the knowledge-based JFD Life 
Cycle. SoS/systems are systems engineered to requirements through JCIDS/DAS with 
multi-year development timelines. Neither of the enterprise’s development systems are 
designed to address the episodic nature of joint missions. A deliberate systems engineering 
approach, centered on the complexities of the operation level of warfare, is necessary to 
address the episodic nature of joint warfighting. 

This application of systems engineering at the operational level of war introduces 
a new class of systems: Episodic Enterprise Systems. These joint warfighting systems are 
necessarily developed asynchronously with enterprise capability development schedules in 
order to address the temporal, transitional, and multi-mission characteristics of joint 
operations: “an Enterprise is a complex, socio-technical system that comprises 
interdependent resources of people, information, and technology that must interact with 
each other and their environment in support of a common mission” (Giachetti 2010, 4). 
The DoD, in addition to being an enterprise unto itself, is also composed of large and 
complex organizations (i.e., Army, Navy, Air Force, Marine Corps, DISA, DIA) that 
design, develop, field, and sustain capability in compliance with enterprise policies and 
instructions, and through the application of enterprise methodologies. 

DoD operational level capability is delivered through a Joint Task Force (JTF) 
organizing construct, enabled by SoS capability developed and sustained by multiple 
components of the DoD enterprise. This temporary, or episodic, mission-specific task force 
is established “when the scope, complexity, or other factors of a contingency or crisis 
require the capabilities of at least two military departments operating under a single Joint 
Force Commander” (CJCS 2012b, ix). The JTF operates through a set of disciplined 
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doctrinally based decision support processes (CJCS 2013). Operational environment 
complexities exploited by Nation States and Violent Extremist Organizations that present 
transregional, transnational, and global threats, stress traditional JTF architectures and 
decision-support processes. 

The inherently complex nature of realizing episodic DoD operational enterprise 
capability introduces challenges to the enterprise engineer. Operational level enterprise 
capability is currently not engineered, but rather doctrinally based and task-organized (i.e., 
assembled) for a specified purpose, independently from the core enterprise organizations. 
Additionally, systems or SoS are not architected or designed for the specific operational 
missions but rather to requirements, generally at the tactical level (i.e., “the employment, 
ordered arrangement, and directed actions of forces in relation to each other” [CJCS 2017, 
1-14]). Capabilities from across the DoD enterprise are developed through the enterprise’s 
systems engineering policies and processes. However, due to the episodic nature and 
breadth of operational missions, and the dynamic nature of the operational environment— 
’’the composite of the conditions, circumstances, and influences that affect employment of 
capabilities and bear on the decisions of the commander” (CJCS 2017, xiv)—multiyear 
system/SoS requirements may not reflect rapidly changing operational level needs. 
Furthermore, episodic enterprise systems engineering can be applied to a broader set of 
similar systems in other domains, beyond DoD operational-level enterprise systems. 

G. OPERATIONAL LEVEL CAPABILITY INLLUENCE ON SOS 

Conceptually, the United States will respond to 21st century military challenges 
with globally integrated operations (GIO) (CJCS 2012a). Key elements of this joint concept 
to be operationalized include global command and control, cross-domain synergy, 
integrated physical and information power, and partner integration (CJCS 2016). With 
cyberspace now included as a warfighting domain in joint doctrine (CJCS 2013), 
cyberspace operations, or cyber, must be integrated into all levels of war (strategic, 
operational, and tactical). At the operational level, where the focus is on commander centric 
cognitive decision making, missions may be episodic and supporting systems are 
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assembled from multiple enterprises. Systems engineers must consider these dynamics in 
the architecture and design of capability development. 

Operational concepts for SoS capability development efforts are typically 
documented at the tactical level of war, as seen in the DODAF Operational Viewpoint 1 
(OV-1): High-Level Operational Concept Graphic for a C4ISR architecture (Figure 3). 
This Intelligence-function architecture must integrate with the other six functional areas; 
perform in compliance with authoritative operational context (i.e., Joint Concepts and Joint 
Doctrine); support multiple missions; account for the operational environment; and, 
operate within operational lines of communication, command relationships, command 
authorities, and interagency coordination venues. 



iHE3 

Theater Airlift 


Figure 3. C4ISR OV-1. Source: Vaneman (2015). 


Note that this OV-1 representation is focused primarily at the tactical 
implementation of the system of interest. SoS engineering approaches and activities must 
include the operational level in both architecture and design. Key aspects of this higher- 
level architecture must be considered in order to provide a more representative and 
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complete architecture for SoS and system design activities that recognize and account for 
the cognitive approach to warfighting. 

H. SPECIFIC CONTRIBUTIONS 

This dissertation presents an organizing construct and associative mapping tool that 
enables the systems engineering of episodic joint operational mission capabilities. The 
Operational Mission Architecture Framework (OMAF) organizes the key components of 
joint operational capability into an intuitive framework, orienting systems engineers to this 
critical perspective. With the knowledge-based capability of the enterprise organized 
through the OMAF, the application of enterprise architecture methodologies, such as 
DODAF, can then be executed within both the engineering (JCIDS/DAS) and operational 
(JFD) domains (Figure 4). The Operational Blended Architecture Map (OBAM) serves as 
the integrating mechanism between the knowledge-based capability elements in OMAF 
and the enterprise’s authoritative architecting methodology (DODAF) utilized in 
JCIDS/DAS material solution development. 
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Figure 4. OMAF/OBAM Integration of DoD Capability Development 

Systems. Adapted from CJCS (2017). 


Note that this implementation of OMAF/OBAM addresses the limitation presented 
in Figure 1, specifically the lack of integration between the knowledge-based development 
system for realizing operational capability (in this case, JFD) and the requirements 
oversight and acquisition systems (in this case, JCIDS/DAS). This blended approach 
allows the operational community to communicate, using their own terminology, with 
systems engineers. Systems engineers can, in turn, execute enterprise-architecting 
activities in their own terminology, facilitated by the associative mapping matrix. This 
promotes a more effective and efficient dialogue between mission operators and systems 
engineers than those centered on review and adjudication of engineering and architecture 
products. Together, they deliver an intuitive approach for both systems engineers and 
enterprise stakeholders to converge and achieve operational success for a mission-focused 
enterprise. 
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1. Operational Mission Architecture Framework 

OMAF organizes the key components of DoD’s JFD Life Cycle into a common 
reference architecture, composed of ten Operational Elements (Unified Action, 
Organization, Operational Design, Operational Actions, Assessment, Operational 
Environment, Functions, Operational Context, SoS, and Mission), for mission stakeholders 
and systems engineers to achieve unity of effort for realizing joint operational capability 
(Figure 5). The organizing construct provides a visual reference that orients stakeholders 
to the foundational components of joint operations, as defined in joint doctrine (CJCS 
2013): achieving Unified Action; executing Operational Core functions; scoping the 
Operational Environment; and, integrating, synchronizing, and directing mission essential 
operations. 


Operational Mission Architecture Framework 

Operational Context 

•Concepts ‘Doctrine ‘Lessons Learned 

Unified Action 

• Lines of ‘Command ‘Command ‘Inter-organizational 

Communication Relationships Authorities Coordination 

Mission 

•DSCA -NEO ‘PO ‘FHA ‘Combat .Strike ‘Raid ‘DR 

Operational Core 

Organization Operational Design Operational Actions Assessment 

•Op Area -HQ -Forces .Objective-COG-LOO-LOE Planning and Execution -MOE/MOP 

(OA) (B2C2WG) -Termination -Shape-Deter-Seize-Dominate 

•Stabilize‘Enable 

Operational Environment 

•Op Area ‘Information Environment‘Electromagnetic Spectrum‘Systems ‘Technology‘Domain 
(OA) (IE) (EMS) (PMESII) 

• C2 

Integrate/Synchronize/Direct Functions 

• Fires ‘Intelligence ‘Maneuver ‘Protection ‘Sustainment* 

Information 

SoS 

Constituent System 

Constituent System 

Constituent System 

Constituent System 

Constituent System 

Constituent System 

Constituent System 




































Figure 5. Operational Mission Architecture Framework. 


OMAF utilizes existing integrated architecture products, created within the DAS 
and JCIDS constructs. Operational context is defined specifically, using authoritative 
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doctrine and informed by lessons learned from previous operations, in terms of Unified 
Action, Operational Core, Operational Environment, and Operational Functionality. This 
provides an additional structural perspective regarding the operation of SoS (as well as 
their constituent subsystems) in support of broader operational mission objectives that 
would not be possible using traditional SE or SoS processes. Systems engineers are now 
able to develop solutions, using a preferred top-down approach, for the full range of 
operational mission types. 

Rapid technology advancements and access, and adaptive adversaries increasingly 
challenge our ability to deliver relevant operational mission capability through traditional 
doctrinal thinking and legacy industrial-era mindsets. The proposed OMAF explored in 
this research is intended to provide an enabling framing construct and blended approach 
that leverages cultural strengths, accepts operational complexity and uncertainty, and 
bridges communities to achieve unity of effort toward a more adaptive and innovative 
enterprise response to 21st century operational challenges. 

2. Operational Blended Architecture Map 

The organizing construct and design of OMAF is not intended to replace any of the 
DoD capability develop systems, but rather to integrate them and enable the systems 
engineering of the ten Operational Elements of joint warfighting capability. An associative 
mapping tool, the Operational Blended Architecture Map (OBAM), has been developed to 
enable the use of DoD’s enterprise architecture model (Figure 6). The mapping of DODAF 
to OMAF promotes a blended approach to architecting where systems engineers can 
communicate with the warfighter in doctrinally consistent terms while generating 
architecture viewpoints. Since joint operational capability is supported by systems and SoS 
architectures developed under the JCIDS and DAS, the application of existing enterprise 
architecture tools and processes promotes an inclusive and efficient enterprise approach. 
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Figure 6. DoD Operational Blended Architecture Map (OBAM). 


The mapping of the DODAF model viewpoints to the OMAF Operational Elements 
enables a precise architecting effort by the systems engineer and facilitates the desired 
blended approach for the DoD enterprise (Figure 7). The color coding is consistent with 
the DODAF model color codes (Wennergren 2009, 9). The mapping was conducted by 
decomposing OMAF Operational Elements in terms of the standard interrogatives (who, 
what, when, where, why, and how), and subsequently associating them with the applicable 
DODAF model viewpoints. 
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Figure 7. DODAF Model Viewpoint Mapping. 

For example, the purpose of the OMAF Organize HQ operational sub-element is to 
prepare and arrange the command installation (CJCS 2017). Recognizing that the 
command installation has a geographic location (where), personnel (who), mission (what, 
when), and functions/processes (how), the standard interrogatives are who, what, where, 
when, and how for that element. The applicable DODAF Viewpoints for this set of standard 
interrogatives are therefore: All Viewpoint; Capability Viewpoint; Project Viewpoint; 
Operational Viewpoint; Systems Viewpoint; Services Viewpoint; and, Data & Information 
Viewpoint. 

A deeper look at the Project Viewpoint, since the applicability of this particular 
viewpoint to headquarters (HQ) organization may not be intuitive, may have some value. 
The three Project Viewpoints (PV) in DODAF describe “the dependency relationships 
between organizations and projects as well as the organizational structures needed to 
manage a portfolio of projects; a timeline for programs or projects citing key milestones 
and interdependencies; and, a mapping of programs and projects to capabilities” 
(Wennergren 2009, 177). Since the PV is the architecture model that addresses 
organizational structures, it is appropriate (at an architectural level) to utilize the PV model. 
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Furthermore, an operational mission has a beginning, an objective(s), a desired end-state, 
and defined phases that resemble a life cycle, essentially the same elements of a project but 
in a different context, thereby reinforcing the assertion that the PV model is appropriate. 

Stepping back, the mission-level organizational relationships in OMAF are sub¬ 
elements of Unified Action, “a comprehensive approach that focuses on coordination and 
cooperation between the U.S. military and other inter-organizational participants to achieve 
common objectives” (CJCS 2017, x). Operational timelines are elements of Operational 
Design and Operational Phasing. The complete mapping of the DODAF/OMAF elements 
through OBAM can facilitate a more informed dialogue and clarify critical context that 
affects architecture and design of supporting SoS and system capabilities. Through this 
blended approach, OBAM enables a comprehensive cross-community effort, or “Unified 
Action,” for realizing 21st century operational level capability. 

3. Provides Integrating Function for DoD Capability Development 

A DoD-enterprise architecture for developing joint warfighting capability emerges 
from the integrating function of OMAF (Figure 8). The integration of these systems at the 
architectural level is minimally disruptive to the enterprise, as existing 
authorities/processes remain in place. 
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Figure 8. Joint Warfighting Capability Enterprise Architecture. Adapted from 
CJCS (2015b); CJCS (2013); SECDEF (2003). 


I. CONCLUSION 

This dissertation proposes an operational level architecture framework and an 
enterprise approach to develop and deliver joint warfighting capability. Furthermore, it is 
intended to provide the structure and organization to engineer directly at the operational 
level, (accepting the inherent complexity at that level), and seeks to provide missing 
context for traditional enterprise systems/SoS engineering endeavors. All three lines of 
effort are needed to deliver relevant 21st century operational mission capability. 

The pace of change of the operational environment, commercial technology 
advances, emergence of the cyberspace domain, and resurgent adversaries, place 
unprecedented demands on our warfighters. The fielding of time-sensitive capability that 
supports the cognition-based approach of commanders and staffs requires a more inclusive, 
adaptive, and agile approach to developing warfighting capability. The timelines and 
tactical level focus of the traditional reductionist industrial era approach are no longer 
sufficient. 
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A comprehensive development effort, inclusive of systems engineering capabilities 
(i.e., architecting, modeling, design, and analysis), is required to better integrate the joint 
force, provide timely solutions to unique operational challenges, and influence supporting 
system(s) development by the Services and partners. The episodic time-sensitive nature of 
joint operational capability and the complexity of the operational environment typically 
require an enterprise approach to deploy the breadth of capabilities necessary to achieve 
operational mission success. 

Traditional systems engineering in the Department of Defense is a foundational 
element of systems, Systems of Systems, and enterprise systems capability development 
and is codified in DoD policy and instruction. Essentially, the warfighter gets the benefit 
of the engineering mindset as part of an acquisition program or system design/upgrade, 
both of which rely on requirements maturity and clarity and introduce changes that must 
be institutionalized before operational benefits can by realized. 

The OMAF organizing construct and the OB AM blended approach delivered in this 
research provide an architectural framework intended to enable cross-domain dialogue and 
to address vital elements of the operational perspective (relationships, interdependencies, 
and complexities) through systems engineering. Bringing enterprise process owners, 
commanders, operators, and system engineers into better alignment is critical for successful 
SoS architecting and design activities that deliver relevant 21st century warfighting 
capability. 
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II. LITERATURE REVIEW 


The intent of this chapter is to orient the reader to the three capability development 
systems of the United States Armed Forces, as well as the enterprise architecting and 
systems engineering applications for developing warfighting capability: Joint Force 
Development (JFD) Life Cycle; Joint Capabilities Integration and Development System 
(JCIDS); Defense Acquisition System (DAS); and, Department of Defense Architecture 
Framework (DODAF). This dissertation offers an enabling framework for both the 
warfighting and systems engineering communities (a blended approach) to collectively 
develop operational level capability with a common methodological context and 
architecture. 

Specifically, fundamental principles and doctrinal foundations, levels of warfare, 
and JFD Life Cycle will be outlined to provide insight into DoD’s knowledge-based 
approach to joint warfighting capability. With joint operational capability being formed 
from the DoD enterprise, as well as other agencies and partner nations, the application of 
enterprise architecting will be reviewed. Also, the application of systems engineering, to 
include mission engineering (Gold 2018), directly at the operational level will be explored. 

A. JOINT FORCE DEVELOPMENT 

Developing the joint force is accomplished through a continuous systematic effort 
that integrates capabilities developed by the Services and prepares individuals and teams 
to execute assigned missions (CJCS 2013). The joint force development process is closed 
looped and is designed to both improve and sustain joint warfighting capability (Figure 9). 
Rather than being a requirements-based process, joint force development is a knowledge- 
based enterprise where both preparedness of participants and integration of enterprise 
capabilities are critical to mission success. Additionally, the continuous nature of the Joint 
Force Development Life Cycle enables the DoD enterprise to form episodic, event- 
driven/on-demand operational capability supported by individual Service capabilities. 
Three subordinate processes provide operational context for planning and executing joint 
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operations, as well as for SoS development: joint concepts; joint doctrine; and joint lessons 
learned. 


Joint Force Development Life Cycle 



Joint Warfighting 
Capability "Jointness” 


Joint Force 
Development Cycle 

Improve 

Create Sustalr 

J 


Joint Trained and 
Adaptable Force 


Figure VI-1. Joint Force Development Life Cycle 


Figure 9. Joint Force Development Life Cycle. Source: CJCS (2013). 


1. Joint Concepts 

Joint concepts examine military problems and propose solutions describing 
how the joint force, using military art and science, may operate to achieve 
strategic goals within the context of the anticipated future security 
environment. Joint concepts lead to military capabilities, both non-materiel 
and materiel, that significantly improve the ability of the joint force to 
overcome future challenges.(CJCS 2013, VI-9) 

The primary purpose of joint concepts is to provide the joint enterprise a vision for 
conducting operations. The Capstone Concept for Joint Operations: Joint Force 2020 
(CCJO: 2020) for example, introduces the vision of Globally Integrated Operations (GIO) 
in response to disruptive technologies. The document also states that 80% of Joint Force 
2020 is already programmed/under contract (CJCS 2012a). Together, the GIO vision and 
the constraint of 20% availability of forces provide critical architecture and design context 
for operators and capability developers alike. 
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Another joint concept, the Joint Concept for Cyberspace, nests under the CCJO: 
2020 and provides additional insight into how joint concepts influence architecture and 
design. The concept’s central idea is to normalize cyberspace operations. (CJCS 2015c). 
The word “normalize” may have connotations, or at the very least considerations, at both 
the operational and SoS levels, to include governance, business and technical processes, 
lexicon, interoperability and integration, command and control, coordination, architecture, 
and design (Figure 10). 


(U) Key Elements of 
Normalized Joint Cyberspace Operations 

• (U) Integrate CO into the intelligence, plannmg. and 
targetmg processes and operations 

• (U) CO-ready jomt force 

• (U) Agile, flexible, reliable, and rapidly deployable 
common network architecture 

• (U) Synchronized situational awareness of cyberspace 
and the other domains 

• (U) Responsive CO approval process 

• (U) Partnerships with other agencies and governments 

• (U) Command and control 

• (U) Rapid capability' development 


Figure 10. Normalized Joint Cyberspace Operations Key Elements. 

Source: CJCS (2015c). 


2. Joint Doctrine 

Fundamental principles and authoritative guidance for employment of joint forces 
is provided in joint doctrine. As such, systems engineers must architect and design 
capabilities that ensure alignment with authoritative guidance. To reinforce this assertion, 
Joint Publication 1, Doctrine for the Aimed Forces of the United States authoritatively 
states that 

This publication is the capstone joint doctrine publication and provides 
doctrine for unified action by the Armed Forces of the United States. It 
specifies the authorized command relationships and authority that military 
commanders can use, provides guidance for the exercise of that military 
authority, provides fundamental principles and guidance for command and 
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control, prescribes guidance for organizing and developing joint forces, and 
describes policy for selected joint activities. It also provides the doctrinal 
basis for interagency coordination and for U.S. military involvement in 
multiagency and multinational operations. (CJCS 2013, i) 

Joint Doctrine is comprehensive, with publications spanning levels of war, joint 
operations, and joint functions. This collection of enterprise knowledge is extensive and 
evolves through doctrinal publication updates that are intended to keep pace with approved 
joint concepts, inputs from the joint force, and lessons learned from joint operations and 
joint exercises. Both the hierarchy and fluidity of joint doctrine can be seen in Figure 11, 
with forty one percent of the publications being modernized. 


JOINT DOCTRINE HIERARCHY 



Figure 11. Joint Doctrine Hierarchy. Source: Rowlett (2013). 


At the operational level, authoritative guidance is promulgated through Joint 


Publication 3-0: Joint Operations, and is even more direct regarding its authoritative 
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nature: “The guidance in this publication is authoritative; as such, this doctrine will be 
followed except when, in the judgment of the commander, exceptional circumstances 
dictate otherwise” (CJCS 2017, i). Operational Art, the cognition-based capability 
previously discussed, is supported by Operational Design: “the conception and 
construction of the framework that underpins a campaign or major operation plan and its 
subsequent execution” (CJCS 2017, xii). This statement indicates that this higher-level 
design component for joint operations should indeed be considered in the design of 
supporting SoS. For example, a systems perspective of the operational environment, Figure 
12, identifies the interconnected components that influence both operational design and 
SoS capabilities architecture, design, and testing. There will be a deeper look at operational 
design in Section C. The organizing construct in OMAF includes these capstone/keystone 
elements and provides operational and engineering perspectives not explicitly covered in 
the DODAF. 


25 




Figure 12. Systems Perspective of the Operational Environment. 

Source: CJCS (2017). 

The operational environment is influenced by the strategic environment, which is 
continuously changing. Partnerships/alliances and threats emerge, disaggregate, and 
remerge in an unpredictable manner. Additionally, the DoD enterprise will organize into a 
mission specific JTF that will be dissolved once mission objectives have been achieved 
(CJCS 2017,1-3). The episodic and uncertain nature of the environment and the enterprise 
capability employed in the operational environment should influence the systems 
engineering of enterprise capabilities, to include the application of systems engineering 
directly at the operational level. 

3. Lessons Learned 

The third component of joint force development that contributes to operational 
context for systems engineers is the lesson-learned process. This process (Figure 13) 
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includes observing joint operations, conducting analysis, and implementing necessary 
changes across the Joint Force Development Life Cycle and capability development. 



Figure 13. Joint Lessons Learned Process. Source: CJCS (2015a). 

The focus of lessons learned, as stated in JP-1, is 

the conduct of joint operations, as well as the execution of each part of the 
joint force development process, in order to continuously identify and 
assess the strengths and weaknesses of joint doctrine, joint education, and 
joint training as well as strategy, policy, materiel, and supporting military 
systems. (CJCS 2013, VI-8) 

The construct of lessons learned is doctrinally mandated, or authoritative, and 
therefore must be considered by systems engineers. Due to the breadth of lessons learned 
(operations, policy, materiel, doctrine, etc.), this component of joint force development 
should be considered at the architectural level of a capability development effort and 
continued throughout the systems engineering processes. 

B. ENTERPRISE ARCHITECTURE FRAMEWORK 

Engaging the collective brains of the enterprise’s cognition-based decision 
makers/stakeholders and the rational/analytic systems engineers to deliver 21st century 
operational level capability, begins with defining an operational framework, at the 
architectural level. Maier and Rechtin (2009) point out that frameworks at the architectural 
level are the primary vehicle for standardization and serve much the same purpose as blue¬ 
print standards. Furthermore, Maier and Rechtin emphasize that an architecture framework 
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does not specify information at the detailed design level but rather contains information 
that is needed to represent the purposes of the user. A review of predominate architecture 
frameworks for system(s) development and interoperability follows, with an excursion into 
decision-making frameworks. The intent is to explore how systems engineers can address 
the cognitive art elements of OMAF in architecture. 

1. Department of Defense Architecture Framework Version 2.0 
(DODAF V2.0) 

The DoD mandates, through policy and instruction, the use of DODAF V2.0 for 
Joint Capability Development. This version of the framework acknowledges the distinction 
between services and systems and emphasizes the purpose, scope, and information 
requirements of the architecture (Figure 14). While other frameworks and/or approaches 
can influence DoD architects/systems engineers, DODAF V2.0 is the approved framework. 



Figure 3-1: DoDAF Viewpoints 


Figure 14. DODAF Viewpoints. Source: Wennergren (2009). 


This version of the DoD architecture framework, with fifty-two models/viewpoints, 
serves as the enterprise framework and conceptual data model. Wennergren (2009) 
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explains that it “focuses on architectural data and information required by key DoD 
decision-makers, rather than on developing individual products” (2). Additionally, there 
are twelve categories of data that architectures are to be built upon, Figure 15, as well as 
guidebooks for managers, architects, and developers. Management and modernization of 
DODAF V2.0 will be accomplished through incremental changes with oversight from the 
DoDAF Core Management Group, within the context of a federated enterprise architecture, 
which promotes integration and interoperability. The standardized structure, categorization 
of data, and guidebooks promote consistency across the DoD enterprise. 

As discussed previously, the primary audience for DODAF V2.0 data and 
information are DoD decision makers. However, while DoD capability developers are 
mandated to use DODAF V2.0, operational decision makers, both commanders and staff, 
are expected to be doctrinally compliant. The mandated architecture data categories in 
Figure 13 are not consistent with the doctrinal language at the operational level. This 
disconnect in language (and context) impacts the relationship between operational decision 
makers, architects, and engineers and is further exacerbated by the episodic/time sensitive 
and fluid nature of operational level employment. 


□ Performers 

□ Resource Flows 

□ Information and Data 

□ Activities 

□ Training/Skill/Education 
^Capability 

□ Services 

□ Projects 

□ Goals 

□ Rules 

□ Measures 

□ Locations 


Figure 15. DODAF Data Categories. Source: Wennergren (2009). 


The implementing guidance for DODAF V2.0 also aligns the data categories, or 
meta-model data groups, and “DoD Key Processes” (Figure 16). Both JCIDS and DAS are 
identified. However, JFD, the processes that develops the cognition-based element of the 
joint force, is not included. 
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Table 3.3-1: DoDAF Meta-model Groups Mapping to Viewpoints and DoD Key Processes 


Metamodel Data Groups 

Viewpoints 

DoD Key Proceses 

AV, CV, DIV, OV, PV, StdV, 
SvcV, SV 

JCIDS, DAS, PPBE, System 
Engineering, Operations, Portfolio 
Management (IT and Capability) 

Performer 

CV, OV, PV, StdV, SvcV, SV 

J, D, P, S, 0, C 

Activity 

OV 

J, 0, C 

Resource Flow 

OV, SvcV, SV 

J, s, 0 

Data and Information 

AV, DIV 

J, D, P, S, 0, C 

Capability 

CV, PV, SV, SvcV 

J, D, P, S, 0, C 

Services 

CV, StdV, SV 

P, S, C 

Project 

AV, CV, PV, SvcV, SV 

D, P, S, C 

Training Skill Education 

OV, SV, SvcV, StdV 

J, S, 0 

Goals 

CV, PV 

J, D, P, 0, C 

Rules 

OV, StdV, SvcV, SV 

J, D, S, 0 

Measures 

SvcV, SV 

J, D, S, 0, C 

Location 

SvcV, SV 

P, s, 0 


Figure 16. DODAF Meta-model to Viewpoints and DoD Key Processes 

Mapping. Source: Wennergren (2009). 


Subsequent sections of this dissertation will describe OBAM’s associative mapping 
of authoritative, doctrinally based, operational architecture and mandated DODAF V2.0 
architecture viewpoints. It will then be possible to explore whether DoD cognition-based, 
operational decision makers’ needs can readily be included in DODAF V2.0 compliant 
architecting activities. 

2. Zachman Framework 

One of the most widely adopted frameworks for enterprise architecture 
development is the Zachman Framework (Sowa and Zachman 1992). The two-dimensional 
matrix is organized so that each cell uniquely represents a relationship and entity of the 
enterprise (Figure 17). 


30 























The Zachman Enterprise Framework 1 


Figure 17. Zachman Enterprise Framework. Source: Zachman (2007). 

Enterprise integration relationships are captured horizontally (rows) across the 
standard interrogatives (what, how, where, who, when, and why), and enterprise 
transformation relationships are identified vertically (columns). The resultant enterprise 
operational capability is identified along the bottom row, as enterprise instantiations. The 
Zachman Framework captures the fundamentals of an enterprise architecture (i.e., standard 
interrogatives for the unique roles of the enterprise members) for solution development. 

The DoD enterprise has tried to take advantage of this approach and mapped 
enterprise architecture levels to the Zachman Framework (Figure 18) for DODAF V2.0. 
Furthermore, DODAF viewpoints are mapped to the standard interrogatives (Figure 19). 
These mappings should foster an enterprise perspective for the DoD architect. However, 
generically mapping two enterprise frameworks omits critical enterprise-specific context 
and values that can affect solution architecture and design. For example, the DoD 
Enterprise’s values and principles are documented in a structured series of authoritative 
documents, called Joint Doctrine (CJCS 2013). Both architecture and design for enterprise 
endeavors must reflect these principles, which are not deliberately addressed in either 
enterprise framework. 
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Table 1.2-3: Zachman Framework with Levels of Architecture 
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Figure 18. Zachman Framework with Levels of Architecture. 

Source: Wennergren (2009). 


Table 1.2.1-1: Standard Interrogates Matrix 



What 

(Date) 

How 

(Function) 

Where 

(Network) 

Who 

(People) 

When 

(Time) 

Why 

(Motivation) 

Viewpoint 

AV, DIV 

OV, SV, SvcV 

OV, SV, 
SvcV 

OV 

CV, OV, PV, 
SV, SvcV 

AV, CV, OV, 
StdV, SV, 

SvcV 

DoDAF- 

described 

Models 

AV-2, DIV-1, 
DIV-2, DIV- 
3 

OV-5a, OV-5b, 
OV-6a, b, c, SV- 
4, SV-lOa, b, c, 
SvcV-lOa, b, c 

OV-2, SV- 
2, SvcV-2 

OV-2, OV-4 

CV-2, CV-4, 
OV-6c, PV-2, 
SV-8, SvcV-8, 
Sv-10c, SvcV- 
10c 

AV-1, CV-1, 
OV-6a, StdV- 
1, StdV-2, SV- 
10a, SvcV-10a 

Meta-model 

group 

Information 
and Data, 
Project 

Activity, 

Capability, 

Service, 

Measures 

Location 

Performer 

All 

Rules, Goals 


Figure 19. DODAF Standard Interrogatives Matrix. Source: 

Wennergren (2009). 


C. ENTERPRISE CAPABILITY REQUIREMENTS MANAGEMENT 

The DoD enterprise manages and prioritizes capability requirements through 
JCIDS (CJCS 2015b). Essentially, the “system” is composed of capability portfolios and 
capability requirements documents for the Joint Force. Requirements validation, and 
interaction with the acquisition system, are guided by JCIDS processes (Figure 20). 
Enterprise architecture products are generated early in the requirements process and 
included in subsequent capability documents, which are passed to the acquisition system 
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for solution development. Prior to entering the JCIDS process, a Capability Gap 
Assessment (CGA) or a similar study to assess requirements, gaps, and risks must be 
completed. The JFD Lessons Learned program is recognized as a source for both 
requirements and gap identification. 



Figure 20. JCIDS Process. Source: CJCS (2015b). 


The organizing construct for integration and management of the multiple factors 
associated with identification, assessment, and validation of requirements can be seen in 
Figure 21. System solutions and architectures are organized by warfighting domains (land, 
air, sea, space, and cyber). Capability Requirements are managed as a portfolio that include 
the operational architectures. This construct also includes alignment of capability 
requirements, strategy, operations, and missions to threats through the application of 
Universal Joint Tasks (UJTs). A “list” of these actionable, commonly understood tasks for 
DoD is maintained through the UJTL Program (CJCS 2014). 
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Figure 21. Capability Mission Lattice. Source: CJCS (2015b). 


Through both the JCIDS process and the Capability Mission Lattice (CML) 
management construct, capability requirements are identified, documented, decomposed, 
and allocated for solution development. This is consistent with traditional systems 
engineering activities. However, the key components of JFD are not considered 
comprehensively, but rather are fragmented. Doctrine is allocated to the solution element 
of the CML when it should be considered together with Joint Concepts and Lessons 
Learned. With this partitioning, operational context is now incomplete and the cognitive 
approach to warfighting is not holistically considered at the operational level. 

D. ARCHITECTURE IN DOD CAPABILITY DEVELOPMENT 

Through the Defense Acquisition System (DAS), materiel solution-based 
capabilities are developed, fielded, and sustained for the DoD (SECDEF 2003). The system 
includes an acquisition management framework, as well as a requirements management 
process, and utilizes integrated architectures to integrate requirements and acquisition. The 
management framework, Figure 22, includes milestone decisions to assess readiness to 
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move through the development phases. Requirements documents, generated through 
JCIDS, are required for Milestones A, B, and C. 
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Figure 22. Defense Acquisition Management Framework. 

Source: SECDEF (2003). 


The process relationships, Figure 23, between requirements and acquisition are 
intended to achieve balance between requirements, capability, and resources. 
Requirements definition and technology maturation are considered throughout the process 
to promote a disciplined approach toward affordable systems and production. An Initial 
Capability Document (ICD) supports a concept decision to begin concept refinement and 
the Milestone A decision to move forward with technology development. The Capability 
Development Document (CDD) is required for a decision to begin system development at 
Milestone B. Lastly, a Milestone C production decision is informed by a Capability 
Production Document (CPD). The requirements documents (ICD, CDD, and CPD) are 
produced through the JCIDS process. These documents therefore also provide 
requirements and acquisition process integration points. Requirements are then informed 
by the solution development effort, and the solution development effort is then informed 
by requirements as the effort progresses. 
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Figure 23. Requirements and Acquisition Process. Source: SECDEF (2003). 

Integrated architectures, developed in compliance with DODAF, drive the 
development of plans that guide capability assessments, systems development, and 
investment decisions (SECDEF 2003). Both the requirements community and the 
acquisition/technical communities work collaboratively to develop the architecture 
products. The foundation for all integrated architectures, for all acquisition programs, is 
the Global Information Grid Integrated Architecture. The DoD Chief Information Officer 
(CIO) is responsible for its development (SECDEF 2003). This approach implies that 
interoperability and integration with the Global Information Grid (GIG), or information 
technology (IT), is the primary objective of the architecture effort. Furthermore, it implies 
that integrated architecting is an IT effort rather than a comprehensive capability 
architecting effort. 

This skewing of the architecting effort toward IT during material development, and 
the fragmenting of the JFD components during requirements definition further obscure the 
operational context and JFD knowledge based capabilities necessary for operational 
capability. 
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E. SYSTEMS ENGINEERING CONSIDERATIONS 


In order to contextualize OMAF within the existing systems engineering literature 
three areas must be reviewed: episodic systems, operational systems, and episodic 
operational systems. Note that these are not generally used terms in the systems 
engineering literatures, accordingly the relevant literature spans a number of distinct fields, 
specifically enterprise systems engineering, system of systems engineering, and systems 
architecting. 

1. Episodic Systems 

There are a number of approaches for developing enterprise capabilities. For 
example, existing enterprises may undertake strategy-initiated, subsystem level, or 
continuous improvement efforts (Giachetti 2010). Similarly, the DoD as an enterprise 
achieves alignment to strategy through the JCIDS process, subsystem development is 
executed through the DAS, and continuous improvement through the JFD Life Cycle (i.e., 
lessons learned, and training). The DoD enterprise also requires episodic capability: 
specific to a particular mission, limited in duration, and occurs at irregular intervals 
( Merriam- Webster 2018). 

Relevant to this research and the episodic nature of DoD missions, Baumeister and 
Striffler (2015) explored systems development for episodic decision support capability. 
Knowledge-driven Decision Support Systems (DSS), which use problem-solving 
capabilities to derive courses of action for specified problems, loosely correlates with the 
knowledge-based approach to joint operations. The Knowledge Base and new/updated data 
available components of the decision-making process model in Figure 24 can be associated 
with the Joint Doctrine and Joint Lessons Learned elements of JFD, respectively. 

Note that OMAF/OBAM are focused on definition of a framework to support 
enterprise level decisions and capabilities, while Baumeister and Striffler present an 
approach for the capture and reuse of data to support specific capabilities, accordingly the 
two efforts could be used simultaneously. They identify and discuss engineering 
challenges. Their recognition that aspects of the knowledge domain are not clearly 
understood by the technical community and that decisions are based more on “past 
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experience, evidence, and intuition ” certainly resonates with the motivation for this 
research (Baumeister and Striffler 2015, 46). 



Figure 24. Decision Making Process. Source: Baumeister and Striffler (2015). 


The engineering of capability for joint operations first needs to be organized at the 
architectural level due to scope (multi-mission/domain) and complexity (operational 
environment), before process modeling is undertaken. Engineering activities, like process 
modeling, can then be executed without losing mission-critical context. 

2. Operational Systems 

The application of systems engineering directly to operations (vice the systems that 
enable operations) has been recently explored and is both extremely relevant to this 
research and encouraging to this researcher. The National Academy for Engineering and 
the United States Institute of Peace (USIP) conducted a workshop to explore the concept 
of operational systems engineering in support of their peacebuilding mission (Robertson 
and Olson 2013). The term operational systems engineering is defined as: 

Operational systems engineering is a methodology that identifies the 
important components of a complex system, analyzes the relationships 
among those components, and creates models of the system to explore its 
behavior and possible ways of changing that behavior. In this way, it offers 
quantitative and qualitative techniques to support the design, analysis, and 
governance of systems of diverse scale and complexity for the delivery of 
products or services. (Robertson and Olson 2013, 1) 
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USIP has similar operational challenges as the DoD. Peacebuilding missions are 
also complex, with multiple relationships to manage in a conflict environment and the need 
for mission specific solutions. Workshop participants acknowledged that the peacebuilding 
community had limited ability to apply systems engineering, and that systems engineering 
should be included in peacebuilding efforts at all levels (from the field to management 
organizations). Both computational and relational modeling techniques were explored in 
the workshop. Building upon a DoD Joint Irregular Warfare Analytic Baseline (JIWAB) 
model (Wong et al. 2017), the Causal Loop Diagram in Figure 25, illustrates the value of 
systems maps for identifying unexpected operational behaviors (through both positive and 
negative feedback). 



Figure 25. Systems analysis of South Sudan. Source: Robertson 

and Olson (2013). 


Consistent with the DoD enterprise (i.e., DoD Joint Doctrine), USIP also developed 
guiding principles (Figure 26). Participants suggested that operational systems engineering 
could be applied for analysis of these guiding principles, several of which are thematically 
consistent with elements of DoD’s Joint Doctrine. The cross-cutting principle of Unity of 
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Effort for USIP missions correlates with DoD’s Common Operating Precept, by the same 
name, as characterized in Joint Doctrine (CJCS 2017). Unity of Effort for USIP missions 
“begins with a shared understanding of the conditions. It refers to cooperation toward 
common objectives over the short and long term, even when the participants are from many 
different organizations with diverse operating cultures” (Robertson and Olson 2013, 11- 
12). Interagency Unity of Effort, for DoD, is realized through unified action and “can only 
be achieved through close, continuous interagency and interdepartmental coordination and 
cooperation, which are necessary to overcome discord, inadequate structure and 
procedures, incompatible communications, cultural differences, and bureaucratic and 
personnel limitations” (CJCS 2013, 11-13,14). Another consistency worth noting can be 
found in the cross-cutting principle/operating precept of transformation/transition. For 
USIP missions, “conflict transformation guides the strategy to transition from violent to 
peaceful means of conflict resolution” (Robertson and Olson 2013, 12), while DoD seeks 
to “plan for and manage operational transitions over time and space” (CJCS 2017,1-3). 
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Figure 26. USIP Guiding Principles. Source: Robertson and Olson (2013). 


Also explored in this workshop, as part of the larger operational systems 
engineering topic, was the value of frameworks for enabling a systemic process for 
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programming and mission assessment. The Conflict Assessment Framework (CAF) 2.0 
(Figure 27) was developed by United States Agency for International Development 
(USAID) to better integrate mission analysis and response. All elements of the framework 
are nested within the context element. 


Context 



Context 

FIGURE 2-2 USAID’s Conflict Analysis Framework 2.0. The framework is used to identify 
current conflict dynamics, possible future trajectories, and potential options for response 
to the crisis. SOURCE: USAID, Reiling workshop presentation. 

Figure 27. USAID Conflict Analysis Framework. Source: Robertson and 

Olson (2013). 

With both guiding principles and a mission framework available, the workshop 
participants acknowledged the importance of modeling to operational systems engineering, 
and that models become more complex when taking a systems approach. This complexity, 
in turn, then makes the models less useful when interacting with operations participants. 

The dichotomy between systems engineering and operations is a motivating factor 
for this research. Additionally, the assertion that operational systems engineering can be 
applied across the levels (tactical/field through strategic/policy) of peacebuilding, and that 
“operational systems engineering offers new and powerful ways of analyzing conflict 
situations and arriving at ways to address them" (Robertson and Olson 2013, 55) is 
consistent with the intent of this research endeavor. 
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3. Episodic, Operational Systems 

Enterprise capability development and the challenges of systems engineering 
episodic and operational systems have so far - been explored. Enterprises also require a 
capability for episodic, operational systems that allow for the timely employment of multi¬ 
mission capabilities in challenging 21st century operational environments. 

Enterprise systems (or enterprises as systems) have been researched in detail by 
Rouse (2006), who focuses on enterprise transformation across a three- to five-year time 
frame. He recognizes that developing system-based capabilities independently within the 
enterprise decreases the enterprise’s potential to succeed, and that alternatively, through a 
combined systems engineering and management approach to transformation, a complete 
enterprise perspective can be included in the transformation effort. 

Rouse further points out the challenges of applying engineering methods and tools 
at the enterprise level. Modeling techniques and tool selection, difficulties associated with 
determining the as-is and to-be states of the enterprise, overcoming the resistance to 
change, the lack of understanding of business processes, and transitioning knowledge and 
information into engineering form requires a substantial effort (Rouse 2006). Also, 
transforming the enterprise requires consideration of technical, behavioral, and social 
perspectives. The impacts to both how the enterprise does work and the social elements of 
the enterprise must be considered when introducing technology changes (Rouse and Baba 
2006). 

Rather than pursuing the above three-to-five year enterprise-wide effort to 
transform enterprise systems engineering, this dissertation addresses the architecture and 
methodology needed to engineer time-critical enterprise capability asynchronously from 
the larger enterprise transformation strategy. The technical, social, and behavioral 
perspectives of the enterprise are instantiated in architecture form to enable DoD 
operations. 

Nightingale has conducted extensive research into ESE, focused primarily on 
frameworks for the transformation of enterprises (Nightingale 2009). The work is 
expanded to include the application of architecting to SoS-based enterprises through the 
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field of engineering systems, which focuses on the enterprise challenges caused by the 
complexity of modern systems (Rhodes, Ross, and Nightingale 2009). Note that this 
research is focused primarily on the as-is and to-be enterprise. This can be contrasted with 
the goals of this intended to propose the creation of a unique mission-focused capability, 
enterprise systems engineering architecture. 

Lankhorst’s research on enterprise architecting, recognizes the ESE view of an 
enterprise, and categorizes the enterprise architecture drivers as internal (e.g., business-IT 
Alignment) and external (e.g., Clinger-Cohen Act requiring government agency IT 
architectures) (Lankhorst 2017). Lankhorst also explores the various architecture 
frameworks and methods (e.g., ArchiMate) to include DODAF, for developing enterprise 
architectures. The approach however, does not adequately address the application of 
enterprise architecture tools as part of a larger systems engineering methodology to realize 
unique mission-focused capability asynchronously from the larger enterprise. 

Rebovich (2005) views government enterprises as “nested” with virtual boundaries 
that depend on the participants, and offers an operational definition of the enterprise as “the 
set of interdependent elements (systems and resources) that a participating actor or actors 
either control or influence. The remainder of the elements constitutes the enterprise 
environment” (2-3). He further explores how to evolve the enterprise in concert with 
traditional systems engineering efforts. Consistent with the previously cited research on 
engineering enterprises, the objective is to transform (or evolve) the enterprise however it 
is defined. A methodology to deliver time-sensitive, asynchronous, and unique episodic 
enterprise capability goes beyond such evolution of systems and processes. For the DoD 
enterprise, operational missions are unique and time-sensitive. Although the enterprise 
certainly has an opportunity to learn and evolve from each mission through a formal 
Lessons Learned program, a systems engineering methodology and architecture to deliver 
episodic operational capability is still not adequately addressed. 

Goranson (1990) recognizes the need for enterprise agility and proposes metrics 
within a three-step process that allows managers to make informed decisions: assess the 
threat; evaluate ability; select tools and techniques. The research looks at the benefits of a 

combined virtual enterprise strategy that accepts diverse perspectives as an approach to 
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achieving agility, particularly in the manufacturing of system-based capability. Although 
the central idea of making metrics-informed decisions and leveraging diversity to achieve 
agility can broadly be applied to episodic enterprise capability, the research focuses on only 
the temporal aspects of enterprise transformation. The methodology delivered through this 
endeavor however, provides the missing reference architecture and associated architecting 
approach to deliver episodic enterprise systems that achieve the desired time-sensitive 
mission capability. 

Sitton and Reich recognize this unique challenge. Their research proposes an 
approach to overcoming the gaps in ESE, SOS, and SE approaches to realizing modem 
enterprise capability (Sitton and Reich 2015). The central component of their proposed 
approach includes an enterprise operational architecture, which is undefined. 

The authors acknowledge the value of traditional architecture frameworks as a 
communication tool as well as recognizing that the state of the art insufficiently addresses 
the complexities of systems engineering an enterprise. Building upon, as referenced by the 
authors, “a very comprehensive book that covers most relevant theory and methods 
regarding enterprise systems engineering by Giachetti [2011],” they identify a gap in 
addressing unsynchronized systems, particularly in governmental organizations. 

The use of current Enterprise Architectures (EA) frameworks to holistically 
describe enterprise architectures does not sufficiently address the gap. The Zachman 
Framework (Sowa and Zachman 1992) provides a comprehensive view of the enterprise, 
but given that the intended use of Zachman’s Framework is a collection of formal, detailed 
models to support the extended operation of an enterprise, it is ill suited to the rapidly 
changing, potentially dissimilar episodic systems of interest to this research. DODAF’s 
suitability for engineering large, complex systems and its role in DoD’s core capability 
development processes is discussed. However, the authors did not identify JFD as one of 
the “six core processes.” The authors accurately observed that the focus is on deliverables 
(8 categories and 52 viewpoints) and is fairly rigid, making adoption difficult across a 
diverse enterprise. Lastly, the lack of traceability from operational requirements to system 
architectures was identified by the authors. This gap can be reduced by including JFD in 
the architecting effort. 
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The central idea for addressing the ESE and SOS gap is the characterization of the 
enterprise as a System of Arrays as Systems (SAS). The characteristics can be seen in 
Figure 28. This bundling of SOS architectures into enterprise silos correlates well with the 
DoD operational level perspective of SOS capabilities as warfighting functions. The Air 
Force enterprise example specifically identifies Command and Control (C2) Systems and 
Intelligence Systems silos. C2 and Intelligence are doctrinally recognized operational 
functions in DoD (CJCS 2017). 


Table 1. Distinction between SOS and Enterprise SAS 


Key Factor 

SOS 

Enterprise SAS 

Discipline 

Usually one discipline and common language. 

Several disciplines, each one with different language. 

System level 

A planned setup of building blocks (constituent 
systems). A new constituent system (with the same 
functionality of an existing building block) can be 
added or replaced through time. 

An enterprise is composed of unsynchronized arrays of 
systems (silos): each silo operates independently. New¬ 
sy stem offers new capabilities (not necessarily for existing 
functionality), other systems can vanish through time 
because of local constrains. 

Processes level 

Several coherent processes as integrated functionality of 
SOS. 

Many cross-enterprise processes, each process is based on a 
different set of systems and silos, different requirements to 
support different operators’ decisions in different silos. 

Inconsistent requirements for different silos are a major 
complexity factor that should be handled to reach coherent 
Enterprise operational architectures. 

New planned integrated and coordinated capabilities that cross 
enterprise arrays may not be achieved as planned because of 
local system/silo constraints resulting in a crash in the 
coordination effort. 

Project level 

SOS system development is handled as a project by 
itself. The project has clear goals and both start and 
end points. New blocks or versions arc handled as 
projects as well. 

Enterprise development over time does not have clear start and 
end points. Its goals are strategic and not easily translated to 
tactical goals of each system. 

Improvement in cross-enterprise processes can be achieved by 
defining strategic goals and road maps for long term 
transformation. 


Figure 28. Enterprise SoS and SAS Distinction. Source: Sitton and 

Reich (2015). 


The foundation for the proposed ESE approach, Figure 29, includes an operational 
architecture at the core. Although the authors recognize the importance of the architecture, 
it remains conceptual/undefined. Other elements of the foundation loosely align with 
elements in JFD. For example, an Operational Process Monitoring Center is included in 
the approach. Operational processes in the DoD enterprise are monitored through the JFD 
Fife Cycle and updated through both the joint doctrine and joint lessons learned processes. 
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Also, the concept of an Integration Test-Bed aligns with JFD joint exercises and training 
where integration of knowledge, systems, and partners is assessed. 
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Figure 29. Foundation for New ESE Approach. Source: Sitton 

and Reich (2015). 


Enterprise capability development occurs at different levels of the enterprise. Also, 
SOS operations may be unsynchronized and independent from other enterprise systems. 
An approach, centered on the operational architecture, to address this dynamic is proposed 
here. Gaps in the ESE, SOS, and SE approaches and enterprise architecture toolsets are 
mitigated by organizing enterprise systems into capability arrays/silos, thereby allowing 
enterprise operational processes to be managed as discrete engineering efforts from the 
array/silo engineering efforts. 

4. Mission Engineering 

Legislation for the DoD to establish Mission Integration Management (MIM) 
activities was included in the 2017 National Defense Authorization Act (NDAA). Six areas 
of responsibility for establishing MIM activities were identified, including research and 
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development, systems engineering, mission driven requirements, experimentation, 
exercises, and Combatant Command coordination. Mission Engineering (ME), “the 
deliberate planning, analyzing, organizing, and integrating of current and emerging 
operational and system capabilities to achieve desired warfighting mission effects” is the 
overarching engineering approach for MIM implementation (Gold 2018). Conceptually, 
ME seeks to integrate material solutions into a SoS architecture that supports the specific 
operational mission (Figure 30). 



Misslon/SoS 

Architecture/Engineering 


Figure 30. Mission Engineering of Operational Mission Capability. 

Source: Gold (2018). 


Currently, this enterprise shift from engineering systems to engineering missions 
requires the identification of criteria for mission outcomes and success, as well as the 
means of measuring mission progress. However, each operational mission is unique and 
typically time-sensitive, challenging the broad ME approach. Additionally, the difficulties 
of bridging engineering and mission effects, gaining access to critical data and information 
across the enterprise, addressing mission complexity, and resource shortfalls impede the 
implementation of ME. 

Within MIM, the fielding of mission capabilities will be realized through ME 
activities that contribute to iterative SoS capability (Figure 31). The first two ME activities 
- Sponsorship and Oversight, and Mission Characterization - involve the Vice Chairman 

Joint Chiefs of Staff (VCJCS) and the Joint Staff (JS) to perform mission area prioritization 
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and provide operational context, respectively. Recall that both JCIDS and JFD, which 
include authoritative Joint requirements, Joint Concepts, Doctrine, and Lessons Learned, 
are the responsibility of the JS. Mission Design & Option Analysis, Coordinated 
Implementation, and Fielding & Sustainment ME activities are aimed at materiel 
solution/SoS development and sustainment (Gold 2018). 
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The Mission Engineering activities within MIM (“Mission 
Characterization" through “Fielding & Sustainment Support") will iterate to 
incrementally field capability improvements, as depicted by the System of 
Systems Engineering (SoSE) Life Cycle (wave model) seen below. 
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Figure 31. MIM ME Activities. Source: Gold (2018). 


Also recall that joint warfighting capability is developed through the JFD Life 
Cycle. The proposed ME approach to partially address some components of JFD through 
coordination rather than inclusive systems engineering, may introduce process errors and 
time delays, similar to those in the current DoD materiel development approach. 
Additionally, note from Figure 31 that the target architecture for mission engineering is the 
SoS Architecture rather than the architecture of the mission, which is the Sol. 

Hernandez, Karimova, and Nelson extend the ME definition to include mission and 
support planning, as part of a Mission Engineering and Analysis (MEA) process (A. S. 
Hernandez, Karimova, and Nelson 2017). This approach treats the mission (including 
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mission and support plans) as the System of Interest (Sol) from a systems engineering 
perspective (Wasson 2016), and introduces a mission life cycle that spans from potential 
conflict to mission completion. Through the MEA process, the ME systems acquisition, 
integration, and operations processes are influenced through continuous mission analysis 
and assessment (Figure 32). 



In a notional application of MEA, Hernandez, Karimova, and Nelson explore the 
integration of the Military Decision Making Process (MDMP) framework (Department of 
the Army 2012) for mission planning with the traditional SE VEE Model (Blanchard and 
Fabrycky 2011). Analysis and assessment SE activities were identified and applied to each 
of the seven steps in the MDMP framework. This approach promotes the development of 
viable mission capability solutions utilizing both processes and languages that are familiar 
to the participating operational and SE communities. 
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Through the MEA approach, Hernandez, Hatch, Pollman, and Upton, explore the 
application of scenario based analysis, modeling and simulation, and experimentation to 
support the integration and operation phases of MEA (Hernandez et al. 2018). The MEA 
integration phase focuses on the analysis of the executing organization’s interactions with 
supporting systems and the operational environment. The importance of including 
doctrinal and operational authoritative guidance in integration activities is acknowledged, 
leading to the desired comprehensive analysis of the Sol. The MEA operations phase 
considers all three levels of warfare. Consistent with this research, the authors propose 
focusing on the operational level (referred to as military operations). 

Executing MEA integration and operation phases requires continuous component- 
system integration. However, the process exchanges and analysis tools to support 
continuous analysis for MEA are not developed. To address this tool shortfall, the 
Integration and Operations Support System (IOSS) analytic support tool is being 
developed. The IOSS incorporates wargaming techniques, operations analysis, simulation, 
and experimentation and delivers analytically rigorous results to support decision making 
across MEA phases. 

Both ME and MEA, as the proposed engineering implementation of MIM, provide 
an opportunity for the application of SE to operations/missions. However, although the ME 
literature discusses mission capability, the processes target the SoS architecture, rather than 
the mission (or operations) architecture necessary for a top-down SE approach. MEA 
advances the ME concept to include continuous analysis and mission planning. The 
importance of both the executing organization and the supporting systems interaction with 
the operational environment is also considered in MEA, moving implementation of the ME 
concept closer to the necessary comprehensive approach for delivering operational mission 
capability. 

F. SUMMARY 

As an enterprise, the DoD has three primary systems for developing joint capability: 
JCIDS; DAS; and, JFD. A review of these enterprise systems revealed that JFD, which 
produces knowledge-based capability, is not holistically included in material solution 
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development. As a result, joint context, which should influence system design and 
operations, is not sufficiently included in SOS or system development activities. 
Conversely, episodic operational capability is developed through the JFD knowledge- 
based system. ESE, SOS, and SE approaches are therefore not contributing holistically to 
the fielding of operational capability that is unsynchronized with materiel solutions 
development. 

The proposed ME concept for implementing congressionally directed MIM, is 
essentially an attempt to apply systems engineering at the mission level. Since MIM is 
looking toward the VCJCS and JS to provide operational context and mission based inputs, 
the effort therefore goes beyond the tactical level of warfare and includes the operational 
level. However, the target architecture is still the SoS architecture rather than the 
operational mission architecture. 

MEA indeed advances the ME concept toward the systems engineering of 
operational mission capability by including the analysis of interactions between 
organizations, supporting systems, and the operational environment as SE activities. 
MEA’s recognition that mission planning must be included in the mission Sol addresses 
an operational level element. Also, the inclusion of doctrine and other authoritative 
guidance in integration analysis advances the ME concept. However, the remaining 
elements of an operational mission are not included in MEA. Additionally, the MEA effort 
does not address the need for an architecture at the operational level to support the preferred 
top-down SE approach. 

The DoD enterprise requires both materiel development solutions, i.e., technology, 
and episodic capabilities to operate in the complex 21st century operating environment. 
Current systems engineering approaches, including ME, are simply inadequate for 
developing DoD enterprise operational mission capability. 

Through a broader lens, organizations are increasingly turning toward technology 
to gain a competitive advantage. This review confirmed that capability development needs 
do not always fit neatly into traditional ESE, SOS, and SE approaches. This literature 
search did find a few instances of the systems engineering community venturing into the 
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application of our craft for realizing operational mission capability. The need to increase 
collaboration and interaction between operational and technical organizations, the value of 
operational frameworks and guiding principles, and the challenges with applying ESE, SE, 
or SoSE directly to operational systems were consistent. However, the operational 
frameworks and architecting enablers to engineer and deliver this capability were not 
developed beyond a conceptual level in any of the literature reviewed, indicating the value 
of the architecture framework and enterprise approach developed through this research to 
enable the systems engineering of episodic operational capability. 
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III. OPERATIONAL MISSION ARCHITECTURE FRAMEWORK 


The focus of this chapter is presentation of the Operational Mission Architecture 
Framework (OMAF) and a description of the applicability of OMAF as an enable of 
episodic operational capability. Given that OMAF is intended to support realization of Joint 
Warfighting Capability, an overview of the elements of Joint Warfighting Capability is 
presented. Specifically, the key elements of Joint Warfighting Capability are discussed: 
Unified Action, Operational Core, Organization, Warfighting Functions, Missions, 
Operational Context, and Systems of Systems. 

Although the above key elements are expressed in the natural language of the DoD 
enterprise, the purpose of architectures in the systems engineering process is not specific 
to DoD capability development. Furthermore, episodic and mission-capabilities are 
interchangeable and apply beyond the DoD, and are generalizable to any enterprise natural 
language and interrogatives. 

A. JOINT WARFIGHTING CAPABILITY 

Often called the “linchpin” of the joint doctrine publication hierarchy, the 
overarching constructs and principles contained in this publication provide 
a common perspective from which to plan and execute joint operations 
independently or in cooperation with our multinational partners, other U.S. 
Government departments and agencies, and international and 
nongovernmental organizations. (CJCS 2017) 

The DoD recognizes three levels of warfare: strategic; operational; and, tactical 
(Figure 33). Strategy is linked to tactics through the operational level, where the 
concentration is on the planning, execution, and assessment of joint operations. There are 
no firm boundaries between warfare levels; however, they provide perspective for 
operations arrangement, resource allocation, and task assignment. JP 3, Joint Operations, 
is the keystone authoritative document, in a series of joint operations publications (JP 3— 
01 through JP 3-72). 
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Figure 1-2. Levels of Warfare 

Figure 33. Levels of Warfare. Source: CJCS (2013). 


Considering the breadth and depth of this body of enterprise knowledge and the in¬ 
stride knowledge gained through the JFD Joint Lessons learned program in systems 
engineering activities is critical. Independent of specific mission types (i.e. Disaster Relief, 
Humanitarian Assistance, or Combat) JP 3 describes the foundational constructs for joint 
operations. 

1. Unified Action 

Operating as a cohesive joint force involves more than interoperable and integrated 
systems and processes. At the operational level of war, the concept of Unified Action 
includes synchronization, coordination, and integration with participating organizations, 
both governmental and nongovernmental (Figure 34). 
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Unified Action 



The joint force commander plans, coordinates, synchronizes, and, when appropriate, integrates 
military operations with the activities of other governmental and nongovernmental entities to achieve 
unity of effort. 


Figure 34. Unified Action. Source: CJCS (2017). 

Achieving Unified Action in an operational area (OA) involves cultivating 
relationships within authorities and responsibilities to synchronize and integrate activities. 
Unified Action leads to Unity of Effort. If not realized, the resultant loss of life and 
instability can place the mission at increased risk. Enablers for Unified Action include: 

• Designated authorizations for command of a joint force. 

• Relationships derived from designated authorizations. 

• Information and supply connections for C2 and relationship management. 

• Coordination with partners to achieve objectives 

Achieving Unified Action and subsequently Unity of Effort, has relationships and 
interdependencies that reach in, through, and across SoS/systems architecture and design. 

2. Joint Command and Operational Core 

Command extends beyond the rote exercise of designated authorities and includes 
leadership ability. JP-3 refers to this more comprehensive view as the art of command 
where the ability to organize, plan, design, execute, and assess are central to effective 
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command. This cognitive approach, or operational art, extends beyond the commander and 
includes the staff (Figure 35). From an enterprise perspective, operational art performs the 
higher-level function of relating strategic objectives to tactical objectives/actions. 



Figure 1-4. Relationship Between Strategy and Operational Art 


Figure 35. Strategy and Operational Art Relationship. Source: CJCS (2017). 


Systems engineers must recognize that command, as well as the control of forces, 
encompasses both cognitive abilities gained from JFD and enabling SoS/systems 
capabilities when architecting and designing both episodic and enterprise 
systems/capabilities. 

Identifying critical objectives will depend more on judgment than on 
calculation, because framing objectives to achieve broad and enduring 
results is more art than science. (CJCS 2017, II-5) 

The underlying framework of a joint operation, first visualized through operational 
art, is conceived and constructed through operational design. This creative process 
encompasses both the planning and execution activities of an operation. The framework 
elements include: 

• Determining objectives in order to gain an advantage. 

• Identification of focal points or centers of Gravity (COG) 
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• Provide time and space orientation, or line of operation (LOO) 

• Align intent, cause and effect through line of effort (LOE) 

• Determine criteria for termination. 

The primary purpose of operational design is to “distill clarity from complexity for 
decisive action” (Reilly 2012, 1). Consistent with any design process, the characteristics 
and dynamics of the operational environment must also be considered. Specific operating 
areas, friendly and adversary systems, technologies, information, and operating domains 
can all influence design. 

The DoD enterprise uses a common model for both planning and executing joint 
operations (Figure 36). This construct includes six groups (also referred to as phases) of 
typical mission activities. Shaping activities involve the setting of conditions for successful 
mission execution. Preventing undesirable adversary actions is accomplished through 
deterring activities. Seizing the initiative is intended to end the crisis as early as possible. 
Controlling the OE or discouraging the adversary from continuing undesirable actions is 
accomplished through dominate activities. Stabilize activities seek to provide a secure 
environment and restore local stability. Lastly, assisting civil authorities to regain 
governance abilities is accomplished through enabling activities (CJCS 2017). 
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A Notional Joint Combat Operation Model 
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• The model depicts six general groups of military activities that typically comprise a single joint 
combat operation. The model applies to a large-scale combat operation as well as to a combat 
operation relatively limited in scope and duration. It shows that emphasis on activity types shifts as 
an operation progresses. 

• Operation shaping activities may begin during plan development to help set conditions for 
successful execution. They may continue after the operation ends if the command continues to 
maintain an operation plan. 

• Theater and global shaping activities occur continuously to support theater and global requirements. 
Specific theater and global shaping activities may support a specific joint operation plan during its 
execution. 


Figure V-4. A Notional Joint Combat Operation Model 


Figure 36. Notional Joint Combat Operation Model. Source: CJCS (2017). 


Although aligned to combat operations, the model also doctrinally applies to non¬ 
combat missions, Figure 37, allowing the transfer of skills, tools, and systems across 
mission types. 
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• This is a notional example of the balance of military activities by a joint task force (JTF) responding 
to one type of crisis (foreign humanitarian assistance). There is no pre-existing operation plan in 
this example. Therefore, there are no planned pre-cnsis shaping activities except for theater 
shaping that may generally support unplanned crisis response. Dominate activities might not occur 
depending on the extent of criminal activity and lawlessness and the host nation government's ability 
to control it. Theater shaping activities that support stabilization and enable civil authorities in the 
affected area may increase after the operation ends and the JTF disbands. 


Figure V-6. Notional Balance of Activities for a Foreign Humanitarian Assistance 
Operation 


Figure 37. Foreign Humanitarian Assistance Operation Model. 

Source: CJCS (2017). 
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Measuring the effectiveness of joint force capabilities is accomplished through the 
continuous process of assessment. The completion of tasks, creation of effects/conditions, 
and achievement of objectives are assessed throughout both mission planning and 
execution. The assessment of operations is complex and involves operational environment 
(OE) observations, partner coordination, and timely reporting to support the commander’s 
decision-making. Additionally, assessments at the operational level of war are linked to 
both strategic and tactical assessments (Figure 38). Assessment design must include these 
requirements. 



Figure 38. Assessment Interaction. Source: CJCS (2017). 

3. Organization 

There are three primary organizational areas of consideration for joint operations: 
the joint force, the headquarters, and the operational area (OA). Additionally, the 
geographic OA may span warfighting domains (land, air, sea, space, and cyberspace). 
Other physical factors including terrain, population, supporting infrastructure locations, 
etc., may impact organizing decisions. 

The greater OE may affect organization approach/decisions. It is therefore critical 
to understand the composition and dynamics of the greater OE, beyond the area(s) where 
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the joint force will be operating. In addition to the physical objects and attributes, the 
information environment (IE) in which “individuals, organizations, and systems 
operate/interact to collect, process, disseminate, and act on information” must also be 
resourced and organized (CJCS 2017, IV-1). Information must also be protected which 
may affect physical and functional organization. 

The rapid development and accessibility of wireless commercial technologies, and 
the DoD’s dependence on wireless capabilities places an importance on the 
electromagnetic spectrum (EMS) element of the OE. Organized and integrated EMS 
operations that ensure access to the spectrum are necessary for joint operations. 

Taking a systems view of the operational environment is both doctrinal for the joint 
force and natural for the systems engineer. Through the systems view, the OE is considered 
to be composed of interacting political, military, economic, social, information, and 
infrastructure (PMESII) systems. The intended use and interactions of these systems can 
affect the planning, organizing, and conduct of joint operations and should therefore 
influence systems engineering efforts. 

Organizing the joint forces for an operational mission is influenced by both the 
operational approach and command principles, and can be established either 
geographically or functionally. Interdependence and interoperability between participating 
organizations/systems must be understood and considered when organizing forces. The 
Joint Task Force (JTF) is the organizing construct chosen to execute missions with specific 
objectives and is subsequently dissolved once objectives are achieved, generating a 
requirement for episodic capability. 

Joint force headquarters (HQ) basing and organizing is influenced by mission 
objectives, the OE/OA, operational phase and transitions. Also, the Standing up the 
command headquarters includes a readiness component that requires training and 
exercising, supported by multiple elements of the JFD Life Cycle. Within the HQ structure, 
Figure 39, the systems engineering center of gravity is the cross-functional staff 
organization. 
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Figure IV-2. Notional Joint Force Headquarters and Cross-Functional Staff Organization 


Figure 39. Notional JFHQ Organization. Source: CJCS (2017). 

Through this Boards, Bureaus, Centers, Cells, and Working Groups (B2C2WGs) 
structure, data and information are organized and analyzed to support the command’s 
decision-making and exercise of authority. For example, joint targeting coordination 
boards (JTCBs) are formed to perform an integrating and/or commander’s review function 
in support of the joint targeting process. Data, information, process, organization, 
relationship, communication dependencies/ relationships extend to the SoS joint fires 
capabilities employed in the OA/OE. The emergence of the cyber domain and the 
integration of lethal and non-lethal actions (Joint Staff 2016) affect staff efforts, including 
the targeting process, and can influence architecture and design of the joint fires functions 
and SoS capabilities. 

4. Joint Warfighting Functions 

Related capabilities and activities are grouped together into functions for the 
purpose of supporting the integration, synchronization, and direction of the joint operation. 
Integration of these seven warfighting functions (C2, intelligence, fires, movement and 
maneuver, protection, sustainment, and information) is critical to mission success. A subset 
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of these functions can be tailored as the mission requires. However, C2 and intelligence 
functions are applicable to all missions. 

A more detailed look at the C2 function, from the joint operational perspective, can 
identify requirements for C2 SoS/system architecture and design that may not be obvious 
to the systems engineer. Through the C2 function, the commander exercises authority and 
direction. Decomposing the C2 function, Table 1, provides additional insight into 
supporting SoS/system functionality and interoperability/integration challenges that extend 
across warfighting functions, organizations, and systems. Task 8 for example, requires 
coordination and integration with the Information function, LOC, Command Relationships, 
Inter-organizational Coordination, and B2C2WG. This task can be affected by the OE/OA 
and spans multiple warfighting domains. 


Table 1. C2 Warfighting Function Decomposition. 

Source: CJCS (2017). 


Task 

Number 

Task Description 

1 

Establish, organize, and operate a joint force HQ 

2 

Command subordinate forces 

3 

Prepare, modify, and publish plans, orders, and guidance 

4 

Establish command authorities among subordinate commanders 

5 

Assign tasks, prescribe task performance standards, and designate 
OAs 

6 

Prioritize and allocate resources 

7 

Manage risk 

8 

Communicate and maintain the status of information across the 
staff, joint force, and with the public as appropriate 

9 

Assess progress toward accomplishing tasks, creating conditions, 
and achieving objectives 

10 

Coordinate and control the employment of joint lethal and 
nonlethal capabilities 

11 

Coordinate, synchronize, and when appropriate, integrate joint 
operations with the operations and activities of other participants 

12 

Ensure the flow of information and reports to higher authority 


Similar to the systems view of the OE previously discussed (PMESII Figure 10), 


the C2 function is also viewed as a system, bringing an additional perspective and 
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additional expectations for systems engineers that may not be reflected in approved 
SoS/system requirements through the JCIDS/DAS. 

C2 System. JFCs exercise authority and direction through a C2 system, 
which consists of the facilities; equipment; communications; staff functions 
and procedures; and personnel essential for planning, preparing for, 
monitoring, and assessing operations. The C2 system must enable the JFC 
to maintain communication with higher, supporting, and subordinate 
commands in order to control all aspects of current operations while 
planning for future operations. (CJCS 2017, III-ll) 

Similarly, JP-3 provides critical context as well as defines, describes, and 
decomposes the remaining warfighting functions. In addition to the doctrinal perspective, 
a comprehensive review of the JFD elements should be conducted when developing 
systems. 

5. Missions. 

Requirements for U.S. military systems are founded on the need to conduct 
sustained global large-scale combat, when called upon. These capabilities also enable the 
joint force to respond to additional missions, as needed, that may not be combat related. 
Typical joint missions and descriptions are provided in Table 2. 


Table 2. Joint Missions. Source: CJCS (2017). 


Mission 

Description 

Combat 

Joint Force...operations to achieve national 
strategic directives.. .or protect national 
interests. 

National Evacuation Operation 
(NEO) 

.. .evacuation of noncombatants from.. .foreign 
countries as.. .directed by Department of State 
(DOS) or other appropriate authority due 
to.. .war, civil unrest, or natural disaster. 

Peace Operation (PO) 

.. .multiagency and 

multination.. .humanitarian, reconstruction, 
and military missions to contain conflict, 
restore peace, and shape the 
environment.. .and.. .transition to legitimate 
government. 
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Mission 

Description 

Loreign Humanitarian Assistance 
(LHA) 

.. .relieve or reduce human suffering.. .due 
to... disease, hunger, or privation in countries 
outside of the US. Executed on short notice. 

Strike 

.. .damage or destroy an objective or a 
capability. 

Raid 

.. .temporarily seize an area.. .to secure 
information, cause enemy confusion, capture 
personnel/equipment, or destroy an objective 
or capability. 

Homeland Defense (HD) 

Protect...U.S. sovereignty, territory, 
population, and critical DoD infrastructure... 

Defense Support to Civil Authorities 
(DSCA) 

...military, DoD Civilian/Contract 
personnel/assets/ agencies, and National 

Guard...assistance to civil authorities. 

Disaster Relief (DR) 

Humanitarian response to manmade or natural 
catastrophic events. 


With this breadth of missions, SoS/Systems that have been architected, designed, 
and tested to combat capabilities may exhibit negative emergent behaviors when organized 
unexpectedly and operated in non-combat missions. For example, C2 and intelligence 
functions and Unity of Action, were impacted by relationship, communication, and 
interoperability challenges when conducting FHA, NEO, and DR missions with non- 
traditional partners/systems in austere environments (JCOA 2010; JCOA 2011; JCOA 
2015). 


6. Operational Context 

Joint warfighting capability is developed and sustained through the JFD Life Cycle 
(Figure 7). Joint Concepts provides idea-based solutions to operational challenges that 
advance joint warfighting. The combined activities of concept development and 
assessment, joint training, and joint exercises, result in improved joint warfighting. 
Implementation and sustainment of those warfighting improvements is accomplished 
through joint doctrine development, education, lessons learned, and training and education. 
Lessons learned, along with active engagement, expose joint warfighting gaps and issues 
(CJCS 2013) requiring either a JLD, materiel, or comprehensive/combined solution. 
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Considering this complete body of joint warfighting knowledge from JFD provides the 
authoritative contextual underpinnings for solution development activities. 


7. Systems of Systems 

System capability employed for joint operations is typically in the form of a SoS 
architecture (Figure 3). These systems deliver tactical effects in the OA as well as provide 
information/data for decision-making and react to authoritative direction to meet 
objectives. From the operational level of war perspective, SoS capabilities are aligned to 
functions. Since there are seven recognized joint warfighting functions, alignment of SoS 
capabilities to those functions is necessary. Additionally, this alignment supports the higher 
level direct, synchronize, and integrate purpose of the warfighting functions. 

There are significant complexities to effectively integrating and 
synchronizing Service and combat support agency (CSA) capabilities in 
joint operations. These challenges are not new, and they present themselves 
with consistency. For example, simply getting the joint force to form and 
deploy in a coherent and desired manner requires integration of 
organization, planning, and communication capabilities and activities. But 
to fully employ the joint force in extensive and complex operations requires 
a much greater array of capabilities and procedures to help the commander 
and staff integrate and synchronize the joint force’s actions. These types of 
activities and capabilities center on the commander’s ability to employ the 
joint force and are grouped under one functional area called command and 
control. In a similar manner, many other functionally related capabilities 
and activities can be grouped. These groupings, we call joint functions, 
facilitate planning and employment of the joint force. (CJCS 2013,1-17) 

B. TRANSFORMING JOINT OPERATIONAL KNOWLEDGE INTO 
ARCHITECTURE FORM 

To effectively engage systems engineers at the operational level of the DoD 

enterprise, and subsequently apply systems engineering methodologies to develop episodic 

operational capability, both the operational community and the engineering community 

must find some common ground. Warfare at this level is too complex to simply review and 

assess the plethora of documents and products that describe the as-is and to-be joint force 

(joint concepts, doctrine, lessons learned, reports, assessments, etc.) and subsequently 

provide thoughts/solutions for review/acceptance. Recall from Figure 11 that there are 

more than 83 Joint doctrine publications, as well as revisions to the publications, that 
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provide necessary operational context. Beyond joint doctrine, a cursory review of a single 
joint concept, Joint Concept for Rapid Aggregation (CJCS 2015d), reinforces the 
challenges of an unorganized approach to document/information review. The purpose of 
the concept is to increase speed, effectiveness, and efficiency of the joint force’s ability to 
assemble and organize in response to a crisis. Figure 40 provides some insight into the 
episodic nature of the concept as the joint force rapidly aggregates for an operation and 
then returns to a steady state posture. Through JFD, the joint force will train and exercise 
to operationalize this concept, assessments will be conducted, doctrine will be updated, and 
lessons learned shared/published. Therefore, the state of joint knowledge will likely be in 
motion during any systems engineering endeavor, exacerbating the size and complexity 
associated with an unorganized approach to reviewing joint warfighting knowledge, and 
subsequently realizing sufficient clarity. 


Steady-State 

Global Campaign 
Plans 


Crisis Response 


Limited Contingency Operations 


Ad hoc 
formation 


Force 

Preparations 


y\ formation 

Rapid Aggregotio 


Force 

Enhancements 


Theater Campaign 
Plans 


Flexible 

Deterrent 

Options 


Flexible 

Response 

Options 


Deliberate TPFDD v * A 

Force flow _ 

jregation J EL, 

SubstantiD 

Force Formation m V 

Transition to a post¬ 
response posture 


Figure 2: JCRA Scope. Steady state force preparation through transition to crisis response and limited 

contingency operations 


Figure 40. Joint Concept for Rapid Aggregation Scope. Source: CJCS (2015). 


Furthermore, the relationships and interdependencies of this concept with other 
concepts must be accounted for in systems engineering activities. Figure 41 provides a 
visual orientation. Note that the Joint Concept for Rapid Aggregation supports the Joint 
Force 2020 Capstone Concept for Joint Operations, is nested within the six Joint Operating 
Concepts (JOCs), and is linked with other joint concepts. 
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Figure 3: JCRA within the family of Joint Concepts 

Figure 41. Joint Concept Relationships. Source: CJCS (2015d). 

Recalling that Joint Warfighting Capability is improved through joint concepts and 
created through joint doctrine and lessons learned, those relationships and 
interdependencies must also be understood before the systems engineering effort can 
advance. Lastly, this body of joint knowledge (concepts, doctrine, and lessons learned) 
spans the full range of joint warfighting capability (Strategic, Operational, and Tactical). 

To facilitate meaningful engagement between operators, subject matter experts, and 
engineers toward a harmonized capability development effort, this vast authoritative body 
of joint knowledge requires organization and framing. 

1. Organizing Construct 

The elements of joint operational capability and their purpose are organized in 
Table 3, below. These are the primary contributors to, and enablers of, episodic operational 
level capability as described earlier. The elements are consistent with the doctrinal 
language in the authoritative documents, with a few exceptions. 
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Table 3. Organization of DoD Operational Mission Capability. 


Operational Element 

Purpose 

Unified Action 

Synchronize, coordinate, and integrate government 
and partner activities 

Lines of Communication 

Command Authorities 

Command Relationships 
Inter-organizational 

Coordination 

Information and supply connections 
Authorizations from orders and directives 
Relationships established through 
authorities 

Coordination for achieving objectives 

Organization 

Operational Area 

Headquarters 

Forces 

Prepare and Arrange 

Geographic operational area 

Command Installation 

Assigned or attached military elements 

Operational Design 

Objectives 

Center of Gravity 

Lines of Operation 

Lines of Effort 

Termination 

Construct an operations framework 

Gain an operational advantage 

Identify focal points 

Time and space orientation 
Intent-cause-effect linkage 

Criteria for conclusion 

Operational Actions 

Shape 

Deter 

Seize Initiative 

Dominate 

Stabilize 

Enable civil authorities 

Plan and execute to common actions 

Set conditions for success 

Prevent undesirable actions 

Early crisis resolution 

Breaking the will to resist 

Restore stability 

Support civilian governance 

Assessment 

Measures of Effectiveness 

Measures of Performance 

Measure progress and capability effectiveness 
Desirable effects or conditions created 

Task accomplishment to standards 

Operational Environment 

Identify conditions, circumstances, and influences 
affecting capability employment and decision 
making 

Operational Area 

Information Environment 

Geographic operational area 

Systems, organizations, and individuals; 
collect, process, disseminate, act 

Electromagnetic Spectrum 

Frequency range of electromagnetic 
radiation 

Systems 

Political, Military, Economic, Social, 
Information, Infrastructure 

Technology 

Domain 

Lethal and non-lethal systems and devices 
Land, air, sea, space, cyberspace 

Warfighting Functions 

Command and Control 

Integrate, synchronize, and direct 

Exercise commander authority and 
direction 
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Operational Element 

Purpose 

Fires 

Intelligence 

Movement and Maneuver 

Protection 

Sustainment 

Protection 

Employ weapons and systems to create 
effects 

Understand the operational environment 
Disposition of forces to secure positional 
advantage 

Active and passive defense, technology, 
and emergency management 

Provision logistics and personnel services 
Management, application, and integration 
of information to influence relevant-actors 

Mission 

Task, purpose, and reason for actions to be taken 

Operational Context 

Relevant principles, guidance, and knowledge 

Systems of Systems 

Interoperating warfighting systems 


The model used for both joint planning and execution, Figure 33, is captured in the 
Operational Actions Element, rather than an Element for each. The application to both 
planning and execution is addressed in the Purpose column. This organizing approach 
reduces the number of elements without losing the purpose or contribution. 

The other exception is the Operational Context Element. As described earlier, the 
body of joint knowledge resides in the JFD Life Cycle, and is dynamic. Only by including 
relevant concepts, doctrine, and lessons learned can the full operational context be 
considered in systems engineering activities. 

The Systems of Systems Element is not specifically identified in JP-3. SoS or 
system capabilities are referred to generically as “capabilities” in the joint publication. To 
facilitate discussion with the joint warfighter and acknowledge the existence of 
SoS/systems in operational level capability, they are identified as an Operational Element 
with the interoperability and warfighting perspective captured in the Purpose column. 

The Operational Elements and associated Purpose statements represent the high- 
level requirements for episodic operational capability and are in the common 
language/terminology of the joint community. No further translation or decomposition and 
allocation to system level requirements is necessary for the systems engineer to engage 
with the warfighter and commence systems engineering activities. With the operational 
level of war distilled and organized into ten primary Operational Elements, transition to an 
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architectural representation provides a common vision and point of departure for the DoD 
enterprise’s capability development systems and associated systems engineering 
methodologies. 

2. Framework Design 

Maintaining architectural alignment is critical when developing enterprise 
capability that involves multiple enterprises, organizations, systems, or processes. To apply 
systems engineering at the operational level of war, the initial point of architectural 
alignment will be established as a framework. Recall that a framework, in this context, “is 
a broad overview, outline, or skeleton of interlinked items which supports a particular 
approach to a specific objective, and serves as a guide that can be modified as required by 
adding or deleting.” (Business Dictionary 2017). This approach allows the multiple 
organizations, which contribute to operational level capability, to employ their native 
enterprise/ organizational processes and tools, while maintaining a common architectural 
aim point. 

The design of OMAF was heavily influenced by the art of architecting (Maier and 
Rechtin 2009) and instantiates multiple stakeholder perspectives, immeasurable yet highly 
valued enterprise philosophies, and experiential insight into architecture form. From the 
architecting process, the framework’s shape, structure, and content are indeed an 
architectural representation of the DoD enterprise at the operational level. Each of the 
Operational Elements, previously defined and organized in Table 3, are instantiated in the 
architecture framework. There are several architecture definitions with the nuances aligned 
to different communities of interest. The IEEE Architecture Working Group (AWG) P1471 
definition resonates with this DoD episodic enterprise systems endeavor: 

Architecture: the fundamental organization of a system embodied in its 
components, their relationships to each other and to the environment and 
the principles guiding its design and evolution. Source: (Maier and Rechtin 
2009). 

Recalling that achieving Unified Action leads to the desired Unity of Effort across 
the joint force and partners, this element is placed at the top. Since the commander plays a 
central role in unifying the joint force, this placement is consistent with both the 
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hierarchical command culture of the DoD enterprise and the doctrinal role of the joint force 
commander (Figure 42). 


Operational Mission Architecture Framework 



Figure 42. OMAF Unified Action Representation. 


Operational art promotes unified action. This cognitive approach by both 
commander and staff is focused on integrating ends, ways, and means through the 
organization of the OA, HQ, and forces, design of operations, planning and executing 
operational actions, and assessing the effectiveness of the joint force. These foundational 
activities enable unified action and are therefore the Core elements of the Operational 
architecture and positioned directly under the Unified Action Element (Figure 43). 
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Figure 43. OMAF Operational Core Representation. 


The character and composition of the Operational Environment affects the 
planning, execution, organization, and design decisions made by the commander, 
supported by the staff. The OE is therefore positioned in the architecture directly below the 
operational core (Figure 44). 
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Figure 44. OMAF Operational Environment Representation. 


Joint functions are groups of related capabilities and activities that provide 
integrating, synchronization, and direction support to the commander of the joint force. 
Application of these functions is influenced by the particular operating area and larger 
operational environment. To reflect both the relationship with the operational environment 
and the capability groups, this element of the architecture is positioned between the 
operational environment and the grouped SoS capabilities that enable these functions 
(Figure 45). 
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Figure 45. OMAF Joint Functions Representation. 


System and SoS capabilities are developed through the JCIDS/DAS processes and 
are typically architected, designed, developed, and tested at the tactical level. 
Corresponding DODAF products reflect this level of warfare. These grouped material 
capabilities are viewed as functions from the operational perspective with cross function 
integration (e.g., Information can enhance Fires) critical to mission success. The SoS 
Element is therefore positioned contiguously with the joint functions element and at the 
bottom of the architecture to reflect the tactical perspective from which they are developed 
(Figure 46). 
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Figure 46. OMAF SoS Representation. 


The knowledge-based and material development capabilities of the joint force are 
developed asynchronously. As discussed previously, joint missions are planned and 
executed in compliance with authoritative joint concepts and joint doctrine, and improved 
through Lessons Learned. Relevant operational context (theory, principles, and behaviors, 
respectively) therefore requires consideration of all three of these JFD. Placement of the 
Operational Context Element on the left side of the architecture communicates this all- 
inclusive aspect (Figure 47). 


75 




































































Operational Mission Architecture Framework 


Operational Context 

•Concepts • Doctrine 'Lessons Learned 

Unified Action 

• Linesof •Command ‘Command • Inter-organizational 

Communication Relationships Authorities Coordination 


Operational Core 

Organization Operational Design Operational Actions Assessment 

~ »„_. ur4 . c _„ * ___ Planning and Execution •MOE/MOP 

•Op Area «HQ 'Forces •Objective»COG*LOO*LOE 

(OA) (B2C2WG) .Termination "Shape.Deter.Seize .Dominate 

• Stabilize .Enable 

Operational Environment 

•Op Area .Information Environment .Electromagnetic Spectrum .Systems "Technology .Domain 
(OA) (IE) (EMS) {PM ESI 1) 

• C2 

Integrate/Svnchronize/Direct Functions 

• Fires "Intelligence "Maneuver .Protection .Sustainment* 

Information 

SoS 

Constituent System 

Constituent System 

Constituent System 

Constituent System 

Constituent System 

Constituent System 

Constituent System 
































Figure 47. OMAF Operational Context Representation. 


The DoD enterprise, through JFD, prepares for and executes a variety of joint 
missions when called upon, both combat and non-combat, in compliance with authoritative 
guidance. The Mission Element is therefore positioned on the right side of the architecture, 
spanning the doctrinal elements of the joint enterprise and completing OMAF (Figure 48). 
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Figure 48. OMAF Mission Representation. 


3. Summary 

The DoD enterprise’s knowledge-based approach to joint operations, resides in a 
plethora of authoritative documents, publications, and reports. In addition to inherent 
cultural differences, the ability to systems engineer operational capability, unsynchronized 
with traditional materiel development efforts, is impacted by the complexity and pace of 
change of the operational environment, the complexity of joint operations, and the ability 
to comprehend the enormity of joint knowledge in its current form. Through OMAF, the 
enterprise’s authoritative body of operational knowledge has been distilled down and 
organized into a framework of ten operational elements that are normalized to joint 
warfighting language and arranged in architecture form. Enterprise architecture tools can 
now be applied as part of the systems engineering effort to develop episodic operational 
capability. 

C. OPERATIONAL BLENDED ARCHITECTURE MAP (OBAM) 

The organizing construct and design of OMAF is not intended to replace any or all 
of the DoD capability development systems, but rather to enable the systems engineering 

of operational level capability. This architecture framework promotes a top-down 
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approach, inherent in systems engineering (Blanchard and Fabrycky 2011), rather than the 
bottom-up approach of assembling JCIDS/DAS developed systems to meet higher-level 
enterprise needs. 

This architectural representation of the enterprise is intentionally at a high level of 
abstraction to promote a consistent dialogue with the warfighter and provide a common 
point of departure for systems engineering mission-unique capability. Existing enterprise 
architecture tools can now be leveraged to generate the architecture products necessary for 
solution design. 

High-level system architectures that meet program requirements are first generated 
during the conceptual design phase (Blanchard 2011). With no formal requirements at the 
operational level, recall that DoD enterprise capability at this level is knowledge-based - a 
different approach is needed to identify and develop appropriate architecture products that 
lead to lower-level system specifications. By associating enterprise architecture products 
with the knowledge-based capability, the lack of requirements is no longer an impediment 
to developing a conceptual design. 

1. Operational Element-Enterprise Architecture Framework Association 

Common to both the Zachman Enterprise Framework (Zachman 2007) and the 
DoD’s enterprise architecture framework (DODAF) is the recognition that addressing the 
standard interrogatives (e.g., who, what, when, where, why, and how) is critical to 
architecture development (Wennergren 2009). For DoD materiel development programs, a 
Standard Interrogative Matrix is included in the DODAF version 2.0 implementation 
memorandum, see Figure 19. By mapping OMAF operational elements to the standard 
interrogatives, required DODAF viewpoints can be identified and DoD enterprise 
architecture tools applied at the operational level of warfare. 

For example, the Organization Operational Element has three sub-elements: 
Operational Area, Headquarters, and Forces (refer to Figure 40). Doctrinally, the 
Operational Area is a bounded area within the land, air, sea, space, and cyberspace 
warfighting domains (CJCS 2017). The applicable standard interrogatives are therefore 
“where” and “what.” From the DODAF Standard Interrogative Matrix, Figure 16, the 
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associative DODAF viewpoints are AV, OV, SV, SvcV, and DIV. Similarly, Headquarters 
are organized functionally, with integration and synchronization achieved through bureaus, 
boards, centers, cells, and working groups. Geographic locations are mission dependent 
(CJCS 2017). Applicable standard interrogatives are therefore what, where, who, when, 
and how. The associative DODAF viewpoints from Figure 19 are then AV, CV, PV, OV, 
SV, SvcV, and DIV. Finally, assigned and attached forces are organized geographically or 
functionally (CJCS 2017). The standard interrogatives are therefore: who, what, and where. 
Subsequently, the applicable DODAF viewpoints are AV, OV, SV, SvcV, and DIV for this 
sub-element. After combining the duplicate views in the sub-elements, the associative 
DODAF viewpoints for the Organizational Element of OMAF are AV, CV, PV, OV, SV, 
SvcV, and DIV. 

Each OMAF Operational Element, as described doctrinally, can be associated with 
DODAF viewpoints through this standard interrogative based analysis approach (Table 4). 
This comprehensive architectural representation of the DoD enterprise allows systems 
engineers to move forward in the design process for operational level capability. 
Furthermore, architecture products for JCIDS/DAS developed capabilities can now 
efficiently include this joint operational perspective and execute a true top-down systems 
engineering approach. 


Table 4. Operational Element DODAF Viewpoint Associations. 


Operational Element 

Standard 

Interrogative(s) 

Who/What/When/Where/Why/How 

DODAF 

Viewpoint(s) 

Unified Action 


AV CV OV SV SvcV 
StdV DIV 

- Lines of Communication 

Who What Where 

-AV OV SV SvcV DIV 

- Command Authorities 

Who What 

-AV OV DIV 

- Command Relationships 

Who Why 

-AV CV OV SV SvcV StdV 

- Inter-organizational Coordination 

Who What 

-AV OV DIV 

Organization 


AV CV PV OV SV SvcV 
DIV 

- Operational Area 

Where What 

- AV OV SV SvcV DIV 

- Headquarters 

Who What Where When How 

- AV CV PV OV SV 
SvcV DIV 

- Forces 

Who What Where 

- AV OV SV SvcV DIV 
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Operational Element 

Standard 

DODAF 


Interrogative(s) 

Viewpoint(s) 


Who/What/When/Where/Why/How 


Operational Design 



AV CV PV OV SV SvcV 
StdV DIV 

- Objectives 

Who Where 


- OV SV SvcV 

- Center of Gravity 

Who What Where 

- AV OV SV SvcV DIV 

- Lines of Operation 

Who What Where When 

- AV CV PV OV SV 




SvcV DIV 

- Lines of Effort 

Who What Where Why How 

- AV CV OV SV SvcV 




StdV DIV 

- Termination 

Who What Where When How 

- AV CV PV OV SV 




SvcV DIV 

Operational Actions 

All 

AV CV PV OV SV SvcV 




StdV DIV 

- Shape 



- AV CV PV OV SV 
SvcV StdV DIV 

- Deter 



- AV CV PV OV SV 
SvcV StdV DIV 

- Seize Initiative 



- AV CV PV OV SV 
SvcV StdV DIV 

- Dominate 



- AV CV PV OV SV 
SvcV StdV DIV 

- Stabilize 



- AV CV PV OV SV 
SvcV StdV DIV 

- Enable civil authorities 

1 

f 

- AV CV PV OV SV 
SvcV StdV DIV 

Assessment 



AV CV PV OV SV SvcV 
DIV 

Measures of Effectiveness 

What Who 


- AV OV DIV 

Measures of Performance 

What Who How When 

-AV CV PV OV SV 




SvcV DIV 

Operational Environment 



AV CV PV OV SV SvcV 
DIV 

- Operational Area 

What Where 


- AV OV SV SvcV DIV 

- Information Environment 

Who What Where How 

- AV OV SV SvcV DIV 

- Electromagnetic Spectrum 

What Where 


- AV OV SV SvcV DIV 

- Systems 

Who What When Where How 

-AV CV PV OV SV 



SvcV DIV 

- Technology 

What Where How 

- AV OV SV SvcV DIV 

- Domain 

What Where 


- AV OV SV SvcV DIV 

Warfighting Functions 



AV CV PV OV SV SvcV 
StdV DIV 

- Command and Control 

Who What Where When How 

- AV CV PV OV SV 




SvcV DIV 

- Fires 

What Where When How 

- AV CV PV OV SV 




SvcV DIV 

- Intelligence 

All 


- AV CV PV OV SV 
SvcV StdV DIV 
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Operational Element 

Standard 

Interrogative(s) 

Who/What/When/Where/Why/How 

DODAF 

Viewpoint(s) 

- Movement and Maneuver 

Who What When Where How 

- AV CV PV OV SV 
SvcV DIV 

- Protection 

Who What When Where How 

- AV CV PV OV SV 
SvcV DIV 

- Sustainment 

Who What Where When How 

- AV CV PV OV SV 
SvcV DIV 

- Information 

All 

- AV CV PV OV SV 
SvcV StdV DIV 

Mission 

All 

AV CV PV OV SV SvcV 
StdV DIV 

Operational Context 

All 

AV CV PV OV SV SvcV 
StdV DIV 

Systems of Systems 

All 

AV CV PV OV SV SvcV 
StdV DIV 


Although this analysis was performed for the DoD enterprise, the approach is 
germane to other enterprise architecture frameworks that consider the standard 
interrogatives (i.e., the Zachman Framework depicted in Figure 17). 

2. Enterprise Architecture Framework Mapping 

With the associative analysis complete, OMAF Operational Elements and 
associated DODAF Viewpoints can now be organized into a more useful systems 
engineering form. The Operational Blended Architecture Map (OBAM) for DoD, Figure 
7, is provided again in Figure 49 for ease of reference. 
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Figure 49. DoD Operational Blended Architecture Map. 


OBAM directly maps applicable DODAF viewpoints to the OMAF architectural 
representation of the operational level of war. The color coding is consistent with the 
DODAF framework viewpoint colors (Figure 14). This visual representation of the 
OMAF/DODAF relationship serves as an enabling tool to orient the systems 
engineer/architect to the doctrinal warfighting elements, facilitating engagement with the 
warfighter during both capability development and operations assessment. Through this 
blended approach interactions can be conducted using the warfighter’s and the systems 
engineer’s native terminology, reducing the risk of translational errors between 
frameworks. For example, the warfighter can interact with the systems engineer on 
Operational Area needs/requirements. OBAM allows the system engineer to easily “see” 
that Operational Area is nested in both the Organization and Operational Environment 
elements, and will influence DODAF viewpoints AV, OV, SV, SvcV, and DIV. As 
architecture products develop/mature, the systems engineer can engage the warfighter 
through the OMAF operational elements, rather than expect the warfighter to review and 
comment on specific architecture viewpoints/models. 
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3. Summary 

DoD enterprise architecture tools support the systems engineering of operational 
level capability. Through a standard interrogatives analysis, DODAF viewpoints were 
directly associated with OMAF operational elements. The resultant comprehensive 
mapping, OBAM, provides a visual reference for both the warfighter and architect to 
interact in their respective normal languages, reducing the risk of translational errors 
between frameworks. OBAM also supports a top-down design approach for JCIDS/DAS 
developed SoS/system capabilities. 

D. EPISODIC OPERATIONAL CAPABILITY DESCRIPTION AND 
DEVELOPMENT 

The strategic environment is fluid, with continually changing alliances, 
partnerships, and national and transnational threats that rapidly emerge, 
disaggregate, and reemerge. While it is impossible to predict precisely how 
challenges will emerge and what form they might take, we can expect that 
uncertainty, ambiguity, and surprise will persist. (CJCS 2017,1-3) 

Recall that the purpose of OMAF and OBAM is to aid in development of episodic 
operational systems, currently realized in the DoD context via the JFD Life Cycle. The 
DoD enterprise prepares for joint operations through the JFD Life Cycle and executes 
assigned missions in a complex, uncertain, and rapidly changing operational environment. 
SoS/system based capabilities, developed and maintained through JCIDS/DAS, have life 
cycles driven by validated requirements, process compliance, and acquisition strategies. 
Joint operations however, are not synchronized to either the JFD or JCIDS/DAS 
development life cycles. Furthermore, SoS/system capability may be used for missions that 
were not identified during the formal acquisition process. Operational level capability is 
therefore time sensitive and multi-mission, with a unique mission life cycle. 

1. Episodic Operational Systems Description 

Through the JFD Life Cycle, the joint force prepares for potential operational 
missions. Once a mission is assigned and executed, the force returns to a state of readiness. 
Operational systems must provide warfighting capability throughout the life cycle of each 
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unique mission. From a systems engineering perspective, the episodic nature of joint 
operations can be characterized through four required system attributes. 

a. Temporal 

Systems that support joint operational mission capability must be responsive to 
mission assignment timelines, and return to a readiness state upon mission completion. SoS 
architectures and systems must be responsive to the organizing, designing, planning, 
execution, and assessment elements of a joint operation as well as to the enabling of unified 
action while the mission is active. Post mission, the systems must then support readiness 
activities (e.g., re-equipping, conducting maintenance, training, and exercising). From a 
mission perspective, these capabilities are both time sensitive and temporary. 

b. Transitional 

Episodic operational systems must support the transition from readiness to unique 
mission activities (and back), as well as the transitions associated with mission changes 
and phases. Mission partners, and their respective systems, may not commonly participate 
in readiness activities, and their systems may not be included in typical SoS/system 
development efforts. Systems must also support the phase/activity group requirements of 
the operation (Figure 31), as well as the transitions to/from phases/activity groups. Finally, 
the systems also have to support transitions at the mission level. For example, the joint 
force may be conducting a political operation when ordered to plan and execute a foreign 
humanitarian assistance mission. 

c. Multi-mission 

According to CJCS (2017), “some missions, such as Operation RESTOREHOPE 
in Somalia, can be dangerous and may require combat operations to protect U.S. forces” 
(CJCS 2017, xvii). Table 2 lists the typical joint mission types. SoS architectures must 
support operations that span from major combat, the primary mission for which DoD 
systems are developed, to humanitarian aid missions in austere operating areas. 
Additionally, multiple missions may be executed simultaneously, with different partners 


84 



in separate operating areas. Systems engineers must consider the breadth of missions at the 
operational level during architecture and design. 

d. Asynchronous 

Recall that through the JFD Life Cycle, the joint force develops joint warfighting 
capability. As joint concepts are developed, doctrine updated, lessons learned promulgated, 
exercises and training conducted, and warfighters are educated, the DoD will continue to 
be called upon to plan and execute operational missions as needed. Mission specific 
training and exercising may be conducted to support the transition from readiness to 
operations, for instance in a mission rehearsal. However, the comprehensive knowledge- 
based capability contained in the various JFD Life Cycle organizations, documents, and 
products execute to internal development schedules and enterprise business processes. 
Similarly, material solutions developed through JCIDS/DAS execute to acquisition 
program schedules/life cycles/processes to meet formal requirements. 

Realizing episodic operational systems capability requires a dedicated systems 
engineering effort that is informed by and leverages JFD and JCIDS/DAS efforts. 
Additionally, the systems engineering effort must also inform JFD and JCIDS/DAS so that 
operational level capability gains are sustained. 

2. Episodic Enterprise Systems Development 

Through the JFD Life Cycle, human beings apply human centered processes to 
subjectively identify the systems and integration requirements necessary to deliver a 
knowledge-based operational capability (that varies episodically). With a high-level 
architecture now defined (OMAF) and mapped (OBAM) to the DoD enterprise architecture 
framework (DODAF), tailored systems that are responsive to the episodic nature of joint 
operations can now be systems engineered. 

The operational context and architectural perspective, through OMAF and OB AM, 
also informs JCIDS/DAS developed SOS/system architectures without requiring changes 
to those enterprise authorities, policies, processes, and tools. As previously discussed, the 
pace of change of both the strategic and operational environments, and the episodic nature 
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of joint operations, requires an approach that is not dependent on lengthy efforts typically 
associated with institutionalizing enterprise changes. 

The ideal application of OMAF and OBAM would represent a new reality where 
we seamlessly apply formal engineering and architecture methods specifically designed to 
objectively identify the system and integration requirements necessary to deliver an 
operational mission capability (in a manner that can be repeated episodically). The 
implementing concept in Figure 50, seen previously as Figure 4, positions OMAF to accept 
the output of the existing operational capability process (JFD) and existing enterprise 
systems engineering processes (JCIDS, DAS, etc.) and integrates them to support the 
development of episodic operational systems. 
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Figure 50. Episodic Operational Systems Engineering Concept. 

Adapted from CJCS (2017). 
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For example, lessons learned generated in compliance with the JFD Life Cycle need 
only be aligned with the doctrinally consistent OMAF operational elements. Systems 
engineers can then apply systems engineering methodologies, to include a precise 
application of DODAF, since the viewpoints are already mapped through OB AM. Lessons 
learned solutions can now be systems engineered in support of joint missions, and current 
operational context can be included in applicable DODAF products for JCIDS/DAS 
developed SoS/systems. 

Beyond this single lessons learned component of JFD, OMAF/OBAM enables a 
comprehensive approach for developing episodic operational capability. Systems 
engineers now have Operational Elements as the engineering center of gravity, and an 
architecture framework for a top-down approach to episodic systems development. 

E. ENTERPRISE CAPABILITY DEVELOPMENT SYSTEMS 

INTEGRATION 

As previously presented, the DoD’s knowledge based capability system (JFD) is 
not integrated with the material capability development systems (JCIDS and DAS). By 
defining an architectural framework at the warfighting nexus (operational level of war) 
OMAF/OBAM become the integrating component of a DoD’s joint warfighting capability 
enterprise architecture (Figure 51). 

OMAF/OBAM is designed to leverage existing capability for episodic enterprise 
systems development, and inform existing capability development systems to sustain 
operational capability. 
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Figure 51. Joint Warfighting Capability Enterprise Architecture. Adapted from 
CJCS (2015b); CJCS (2013); SECDEF (2003). 

As an integrating function, OMAF/OBAM: 

1. Organizes JFD Life Cycle document based joint warfighting knowledge 
into a reference architecture for JCIDS analysis and architecting activities. 

2. Organizes JFD Life Cycle document based joint warfighting knowledge 
into a reference architecture for episodic enterprise systems development. 

3. Enables the application of DODAF tools for developing episodic 
enterprise systems. 

4. Provides comprehensive operational context for DAS DODAF products. 

5. Enables precise enterprise architecting through OB AM. 

6. Blends warfighter and systems engineering cultures at the architectural 
level. 

7. Enables a top-down architecture and design approach for the systems 
engineering of operational level capability. 
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The organizing construct and design of OMAF/OBAM allows the DoD enterprise 
to deliver needed operational level capability through integration vice creating and 
operationalizing a new development system. Furthermore, OMAF/OBAM implementation 
also facilitates the establishment of a DoD enterprise architecture for more effective and 
efficient capability development. 

F. OPERATIONAL PLANNING APPLICATION 

Planning translates guidance into plans or orders to achieve a desired 
objective or attain an end state. The joint planning process aligns military 
activities and resources to achieve national objectives and enables leaders 
to examine cost-benefit relationships, risks, and trade-offs to determine a 
preferred course of action (COA) to achieve that objective or attain an end 
state. (CJCS 2017, xii) 

Planning and managing transitions is a common operating precept for the DoD 
(CJCS 2017). The OMAF/OBAM methodology, which addresses the transitional attribute 
of episodic enterprise systems, can also support the generation of key planning documents. 
The same operational elements in OMAF now in systems engineering form for developing 
operational mission capability, are also required for planning. For example, the Operational 
Design element of OMAF provides the “conception and construction of the framework that 
underpins a campaign or major operational plan and its subsequent execution.” (CJCS 
2017, xii) 

From a systems engineering perspective, there are similarities between capability 
development activities and enterprise planning activities. The DoD joint planning process 
includes cost-benefit analysis, risk identification, and options that determine courses of 
action (COA) (CJCS 2017). Systems engineers typically participate in those same activities 
for system-based capability development. With OMAF focused on the operational level of 
the enterprise, the OMAF methodology can therefore be extended to both the planning of 
operations, or Operation Plan (OPLAN), and the identification of branches and sequels 
captured in Contingency Plans (CONPLAN) (CJCS 2017). 
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G. CONCLUSION 

The DoD conducts joint operations in an operational environment that is 
increasingly complex, uncertain, and rapidly changing. These operations are organized, 
designed, planned, and executed as needed, rather than in synchronous with the knowledge- 
based or material capability development schedules. The episodic nature of these joint 
operations challenges the DoD capability development systems. 

Currently, joint warfighting capability, is developed through a knowledge-based 
approach (JFD), without the contribution of systems engineers. Additionally, material 
solutions are developed to system requirements, through different development systems 
(JCIDS/DAS) that are organized into SoS architectures and support joint operations. Both 
individually and collectively, these systems are not positioned to meet the needs of the 21st 
century joint force. 

Defining a reference architecture, at the operational level of war, in the warfighters 
natural language, facilitates the application of systems engineering at the operational level, 
provides critical operational context for material development, and produces a resultant 
enterprise integration function for DoD capability development systems. 

By distilling the plethora of authoritative documents into the ten Operational 
Elements of OMAF, systems engineers are now able to provide capability solutions for 
those elements. Existing enterprise architecture tools (DODAF) can now be leveraged 
through the OBAM associative map, enabling a more precise systems engineering effort 
focused on the Operational Elements of joint warfighting. 

This application of systems engineering at the operational level of war introduces 
a new class of systems; Episodic Enterprise Systems. These joint warfighting systems are 
necessarily developed asynchronously with enterprise capability development schedules in 
order to address the temporal, transitional, and multi-mission characteristics of joint 
operations. 

The OMAF/OBAM architectural approach to joint operational capability 


development enables a top-down systems engineering effort, instead of the bottom-up 
method inherent in the current material development method. This approach also promotes 
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the use of existing enterprise tools and processes within existing authorities, which 
promotes efficiency and minimizes enterprise transitions. 

The cumulative effect of OMAF/OBAM’s purpose, design, and orientation, 
provides the integrating function for forming a DoD enterprise architecture. Without an 
enterprise approach, DoD will continue to be challenged to deliver 21st century joint 
warfighting capability. 
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IV. OMAF/OBAM PROOF OF CONCEPT 


The DoD enterprise prepares for and executes (through the JFD Life Cycle) a 
variety of joint missions asynchronously with materiel capability development schedules. 
Missions may have similarities but each one is unique and often time sensitive, leaving 
inadequate time for mission specific capability development through the traditional 
enterprise approaches. 

As part of the JFD Life Cycle, operational assessments are conducted both in 
support of an operation and to further advance joint warfighting capability by 
institutionalizing the lessons learned. These assessments are documented using doctrinal 
terminology. Recalling that JFD is knowledge based (not systems engineering based), 
mission issues are inherently not in a form that can be resolved through an enterprise 
approach (i.e., inclusive of JCIDS and DAS). However, by associating these issues to an 
architectural representation of joint operations (OMAF), enterprise architecture tools 
(DODAF) native to JCIDS and DAS can now be applied as part of the desired 
comprehensive top-down systems engineering approach. 

Four different operational assessments, spanning different mission types, locations, 
and operating environments were analyzed to demonstrate the utility and range of OMAF. 
Observations/issues were extracted from the text, summarized thematically, and associated 
to OMAF Operational Elements. This approach facilitated the transition from report form 
to architecture form. With the issues now characterized architecturally, the systems 
engineer and warfighter can collaborate on OMAF Operational Element designs that lead 
to the desired capability. The discussion has now transitioned to one of architecting and 
designing solutions without abandoning the warfighting lexicon. 

Specifically, the operational studies examined here were developed by the Joint and 
Coalition Operational Analysis (JCOA) organization of the Joint Staff. Foreign 
humanitarian assistance (FHA), disaster relief (DR), noncombatant evacuation operation 
(NEO), and combat operations (CO) reports were analyzed. These mission types were 
selected because they present different challenges to the joint force that can and should 
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influence architecture and design decisions. For example, both FHA and DR missions may 
be conducted in austere environments. However, following a natural disaster, traditional 
organizations, communications, and infrastructure that systems were designed to operate 
on/with, may no longer be available or accessible, impacting the planned execution. Also, 
a NEO may be conducted in an area where there is hostility and violence. Although not a 
combat mission, the joint force/systems must also be prepared for potential combat. 

A. JOINT OPERATIONAL ISSUES 

The analysis and results for the four JCOA reports follows. In each case, it was 
possible to identify observation/issue themes and the associated OMAF element 
contributors. Not unexpected, challenges with both JFD and SoS/systems were identified. 

1. Decade of War Study 

A comprehensive review of combat operations following the September 11 th 2001 
terrorist attacks on the U.S. homeland spans forty-six JCOA studies (400 different 
observations/issues) conducted from 2003 through 2012 (JCOA 2012). The themes and 
OMAF element associations are presented in Table 5. The time span of this study (a 
decade) alone, provides unique, if not unprecedented insight into sustained joint operations. 

From an episodic enterprise systems perspective, problems associated with 
transitions and timing (both phase and mission), and multiple missions (combat, nation 
building, etc.) were prominent. C2, intelligence, and information capabilities both from a 
warfighting function and systems perspective, consistently did not meet expectations and 
contributed to difficulties in achieving Unified Action. 

Intelligence and information shortfalls also contributed to the inability to 
adequately understand the operational environment and assess the effectiveness of the joint 
force. Furthermore, the shortfalls affected the force’s ability to adapt to changes in the 
operational environment. 

JFD Life Cycle shortfalls were also identified. Joint concepts, doctrine, and lessons 
learned were not keeping pace with joint warfighting advancements in the field. This lack 
of current operational context also impacted the commander’s ability to achieve Unified 
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Action, and affected other OMAF elements, particularly the Operational Core (i.e., design 
and assessment). 


Finally, along with intelligence and information shortfalls, coordination challenges 
with both U.S. and international partners were also prominent throughout the 10 years of 
war. As strategy, missions, situations, and the environment changed, the need to coordinate 
with partners was critical to achieving Unified Action. 

Table 5. JCOA Decade of War Study, Vol.l. Source: JCOA (2012). 


Observation/Issue 

OMAF Element 

Environment Ambiguity 

- Operational Environment: OA/IE/PMESII/ 
Technology 

- Functions: Intelligence/Information 

- Assessment 

Ineffective Approaches 

- Operational Context: Concepts/Doctrine/ 
Lessons Learned 

- Operational Design 

- Functions: Command & Control 

- Organization: HQ/Forces 

- Unified Action: Command Relationships 

Ineffective Narrative 

- Operational Design/COG/LOE 

- Assessment 

- Functions: Information 

- Operational Context: Concepts/Doctrine/ 
Lessons Learned 

- Unified Action: Inter-organizational 
Coordination 

Transitions 

- Operational Actions: Planning and Execution 

- Missions: 

- Unified Action: Inter-organizational 
Coordination 

Adaptability 

- Operational Context: Concepts/Doctrine/ 
Lessons Learned 

- Operational Actions: Planning 

- SoS: Command & Control/Fires/Intelligence/ 
Information 

Integration of Forces 

- Organization: Forces/HQ(B2C2WG) 

- Operational Environment: Op Area 

- Functions: Fires/Command & Control/ 
Intelligence/ Information 
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Observation/Issue 

OMAF Element 

- Interagency Partners Coordination 

- Coalition Partner Operations 

- Unified Action: Inter-organizational 
Coordination 

- Operational Context: Concepts/Doctrine/ 
Lessons Learned 

- Assessment 

Empowered individuals & small 
groups 

-Unified Action: Inter-organizational 
Coordination 

- Operational Environment: Technology/IE 

- Lunctions: Intelligence/Information 


Of note, since this study was conducted in 2012, a new warfighting domain 
(cyberspace) and a new warfighting function (information) have been recognized. 
Additionally, a solution for networking mission partners is now also being developed 
through both JFD and JCIDS/DAS, more than 16 years after the attacks of September 11, 
2001 . 


2. Operation Unified Response 

This disaster relief (DR) joint operation study reviewed the response to the January 
2010 magnitude 7.0 Haiti earthquake. A Joint Task Force (JTF) was formed to lead the 
DoD mission, as part of a larger United States, international community, charitable, and 
private organization response. The study focused on the challenges associated with forming 
and operating a JTF in an operational environment lacking critical infrastructure (JCOA 
2010 ). 

As discussed earlier, the DoD conducts joint operations other than combat when 
called upon. When compared to the Decade of War Study, there were common challenges 
identified. From a functional perspective, intelligence and information shortfalls impacted 
the ability to understand the operational environment and contribute to assessment actions. 
C2 of the JTF was also problematic, as well as execution of the sustainment warfighting 
function (Table 6). 

The inability to assess joint force effectiveness and to coordinate with partners were 
also common issues. The primary contributor to assessment challenges was the devastation 
from the earthquake that disabled traditional lines of communication. The lack of 
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communication channels also affected force flow, logistics, organization of the JTF, and 
the ability to coordinate with partners. 

Of particular interest, are the severity of the issues associated with the non- 
traditional organization of USSOUTHCOM. The effects extended beyond the Combatant 
Command proper and into the JTF’s ability to organize, design, plan, execute, assess. 


Table 6. Operation Unified Response/DR. Source: JCOA (2010). 


Observation/Issue 

OMAF Element 

- JTF-Haiti formation complicated by 
SOUTHCOM non-traditional organization 
Coordinate and communicate with 
humanitarian organizations 

- Unified Action: Inter-org Coordination/CMD 
Relationships 

- Organization: HQ 

- Crisis Action Planning 

- Operational Actions/Planning 

- Lack of Situational Awareness 

- Systems unavailable or unknown to collect, 
process, disseminate, act 

- Lunctions: Intelligence/Information 

- Operational Environment: OA/IE/PMESII 

Lack of Assessment Capability 

- Assessment 

Normal communication channels down 

- Unified Action: LOC 

Lorce deployment decisions 

- Organization: Lorces 

JTL C2 

- Lunctions: C2 

- Joint Logistics Op Center delayed 

- Lorce Llow and RSOI not synchronized 

- Lunctions: Sustainment 

- Organization: Lorces 

- Operational Design: LOO &LOE 


Issues associated with this non-combat mission also span both JFD and 
JCIDS/DAS developed capabilities. By associating the issues to the OMAF elements, 
Multi-mission capability can influence architecture and design of systems typically 
designed to meet combat requirements. Additionally, these DR mission problems are now 
in a form for systems engineering methods and tools to be applied toward resolution. 

3. Operation United Assistance 

The study assessed the foreign humanitarian assistance (FHA) mission conducted 
in response to the West Africa Ebola virus outbreak. DoD support was not initially 
requested. The delay, along with undefined DoD roles and responsibilities, severely limited 
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the reaction time. The outbreak started in December 2013 while the enhanced response that 
included DoD commenced in September 2014 (JCOA 2015). 

Although there are common warfighting function, unified action, and operational 
core issues with the Unified Response DR mission, this FHA mission highlights the impact 
of the time critical nature of the response. Additionally, the austere environment affected 
the ability to perform the Protection warfighting function (Table 7). 


Table 7. Operation United Assistance/FHA. Source: JCOA (2015). 


Observation/Issue 

OMAF Element 

Large planning requirements 

- Operational Actions: Planning/Transitions 

- Organization: HQ/Forces 

- Joint Processes and Capabilities 

- Joint Operations 

- Overwhelmed Staffs 

- Unified Action: LOC/CMD Rel/Inter-org 
Coord 

- Organization: HQ/Forces 

- Operational Actions: Planning 

Functions: 

Intelligence/Sustainment/Information 

- SoS: Intelligence/Sustainment 

- Op Context: Doctrine/Lessons Learned 

Austere Environment 

- Unified Action: Lines of Communication 

- Assessment 

- Operational Environment: IE/PMESII 

Functions: 

Protection/Information/Intelligence 


The prevalent challenges and issues identified with this FHA mission can be 
associated with the JFD Life Cycle and are manifested primarily in the ability to plan and 
manage transitions. As noted previously, the expectation that traditional communication 
channels would be available did not play a role in planning and transition issues, as they 
did in the Unified Response DR mission. The austere environment was the primary 
contributor to those challenges. The need for operational capability that is time sensitive, 
executes transitions, and adapts to a variety of missions was again identified here, as is in 
the previous case studies. 


98 







4 . Operation Odyssey Dawn 

This study of the March 2013 noncombatant evacuation operation (NEO) response 
to the attack on the U.S. Embassy in Libya, centered on command and control challenges. 
The use of an embarked (vice land-based) JTF (USS Mount Whitney), the supporting role 
to the Department of State, increasing violence, joint operating area establishment, and 
larger operational environment influences contributed to the challenges (JCOA 2011). 

This case study is particularly useful in exposing the interdependencies. Even with 
the study focused on the C2 function, unified action, organization, planning, and fires 
functional shortfalls were also identified (Table 8). Also, the lack of guiding principles 
(doctrine) for planning and executing an operation this complex was identified. 


Table 8. Operation Odyssey Dawn/NEO. Source: JCOA (2011). 


Observation/Issue 

OMAF Element 

Large planning requirements 

- Operational Actions: Planning/Transitions 

- Organization: HQ/Forces 

- Joint Processes and Capabilities 

- Joint Operations 

- Overwhelmed Staffs 

- Unified Action: LOC/CMD Rel/Inter-org 
Coord 

- Organization: HQ/Forces 

- Operational Actions: Planning 

- Functions: 

Intelligence/Sustainment/Information 

- SoS: Intelligence/Sustainment 

- Op Context: Doctrine/Lessons Learned 

Austere Environment 

- Unified Action: Lines of Communication 

- Assessment 

- Operational Environment: IE/PMESII 

- Functions: 

Protection/Information/Intelligence 


Executing the NEO mission, required the standup of a JTF while AFRICOM was 
also planning kinetic operations, forming a multinational coalition, conducting multi- 
domain operations, and transitioning responsibility to NATO (JCOA 2011). As discussed 
earlier, there is a nexus at the operational level of war, which is readily apparent here. The 
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episodic nature of joint operations, multi-mission capability, time constraints, and 
transition challenges are apparent. 

5. Summary 

These case studies highlight the breadth and complexity of DoD missions as well 
as the fact that systems developed for the primary purpose of combat operations are also 
used extensively for other missions, with similar challenges encountered. Across the case 
studies of these four different mission types, observations/issues were readily associated to 
OMAF elements, successfully transitioning them into a consistent form for resolution. The 
need for capability that is time sensitive, multi-mission, and transitional to support the 
episodic nature of joint operations was consistently identified. 

B. OMAF REPRESENTATION OF EPISODIC OPERATIONS 

Extracting the issues from the formal JCOA studies and associating them with 
OMAF elements presents those operational challenges in a form that can be characterized 
architecturally. A mapping of the mission issues to OMAF, Figure 52, provides an initial 
architectural representation. The Mission Issue Map provides visual perspective for 
initiating the systems engineering effort toward issue resolution and/or enduring 
operational level capability development. 
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MISSION ISSUE MAP 
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Figure 52. JCOA Studies Mission Issue Map. 

At a glance, common issues that are possibly systemic at the operational level, can 
be identified, or at least guide discussions and analysis. Consistently, the commander’s 
ability to achieve unified action was affected by LOC, command relationship, and partner 
coordination issues, regardless of mission. 

Also, in the core of the architecture, organizing and planning joint operations 
challenged both the commander and staff. These core actions are affected by both the 
Unified Action and Operational Environment elements of OMAF as documented in the 
studies. 

As discussed earlier, the pace of change and complexity of the 21st century 
operational environment challenges the joint force. Ambiguities in the system components 
(PMESII) and the mission operating areas, as well as the inability to collect and interpret 
the information impacted the force’s ability to organize, design, act, and assess (all 
elements of the architecture’s core), as well as the commander’s ability to achieve unified 
action. 
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The intelligence and information warfighting functions, which must be integrated 
with other elements of the architecture, to execute C2 for example, had both functional and 
system issues identified. These were also affected by the challenges with operational 
environment ambiguities and changes. 

Finally, the guiding principles by which the joint force operates; joint warfighting 
theories (concepts), authoritative practices (doctrine), and recently discovered knowledge 
(lessons learned) did not reflect the current state of joint operations. 

The “shot groups” on the OMAF mission issue map provide a visual orientation to 
develop the architecture products for operational level capability. This is a more useful 
form for characterizing solutions and challenges. Systems engineers and warfighters can 
then collaborate throughout both the system and cognition-based capability development 
processes. Essentially, an architectural common point of departure has been established. 

C. OBAM FACILITATION OF DODAF ARCHITECTING 

The desired top-down approach utilizing enterprise architecture tools is initiated 
through the blending of the OMAF and DODAF, as previously discussed. The enterprise 
architecture instantiation of these issues can be seen below (Figure 53). 
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Figure 53. DODAF Instantiation of Operational Issues. 

The OBAM for these case studies demonstrates that the full range of DODAF 
viewpoints can be applied, as with any system capability development effort. Unique to 
this approach however, is the comprehensive application of DODAF tools (both knowledge 
based and material based) for solution development. Recognizing that the use of DODAF 
is common knowledge in the DoD materiel development/systems engineering community, 
a quick look at the knowledge based capability perspective may be of some value here. 

The ability to achieve unified action was impacted by both LOC and Inter- 
Organizational Coordination anomalies. OBAM indicates that the AV, DIV, OV, and SvcV 
are appropriate architecture viewpoints for both operational elements, while the SV is only 
applicable to the LOC element. Recognizing that functioning physical communication 
channels (LOCs) are required to coordinate (interact, exchange information, etc.) with 
operational partners, it seems reasonable that the development of architecture products 
would need to consider both elements. 

Furthermore, since LOCs and partners are critical to mission execution (AV), data 
and information is exchanged (DIV), organizational relationships are agreed upon (OV), 
and partners are included in mission networks (SvcV) these particular architecture products 
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are appropriate. Recalling that the DODAF viewpoints relationship with OMAF Elements 
were generated using the standard interrogatives (Table 4), the SV is not necessary for 
architecting Inter-Organizational Coordination capability. The SV is however appropriate 
for LOC architecture development since partner systems(s) must be included in the mission 
architecture. From Table 4, partner geographic location(s) are addressed through the 
“where” standard interrogative. The SV viewpoint is then introduced into the architecture 
through the standard interrogative matrix (Figure 19). 

The resultant architectural instantiation of these four case studies spanned all 
DODAF Viewpoints. A visual inspection of the OB AM does not indicate any particular 
bias toward either materiel capability development elements (SoS) or the knowledge based 
capability development elements. Systems Engineers/architects are then not constrained by 
either development system. Through this blended approach, the full capability of DODAF 
can be employed at the operational level in concert with focused warfighting community 
collaboration, utilizing doctrinal joint warfighting terminology (OMAF). 

D. SUMMARY AND CONCLUSIONS 

The joint force consistently experiences operational capability challenges across 
mission types. Both the JFD and JCIDS/DAS development systems are contributors to the 
challenges. These operational issues and lessons learned are documented and 
institutionalized through the JFD Life Cycle. Four formal case studies for different mission 
types (Combat, FHA, DR, NEO) were analyzed. Issues were summarized thematically and 
then associated with doctrinally consistent OMAF elements. Using OMAF, a Mission Issue 
Map was generated, successfully transitioning lengthy narratives to a more precise 
architecture form. Challenges common to all mission types can now be identified from a 
visual inspection of the mission issue map. This single visual representation should 
facilitate a focused dialogue between systems engineers and the warfighter during solution 
development. 

The Mission Issue Map displays common, and perhaps systemic issues, with the 
guiding principles for joint warfighting (concepts, doctrine, and lessons learned) developed 
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through the JFD Life Cycle. This indicates that the knowledge-based capability necessary 
for joint warfighting is not keeping pace with operational environment changes. 

Recall that at the operational level, achieving Unified Action (through operational 
art) leads to the desired Unity of Effort. LOC, Command Relationships, and Inter- 
organizational Coordination challenges impacted the commander’s ability to achieve 
Unified Action. Also, both the commander and staff were consistently challenged to 
organize, design, act, and assess as well as to understand the operational environment. 

Issues with both the information and intelligence functions and their associated SoS 
capabilities were prevalent. These shortfalls were the primary contributor to the challenges 
associated with understanding the operational environment. 

With the issues oriented architecturally through OMAF, enterprise architecture 
tools can now be applied. Utilizing the OBAM tool, issues were instantiated in DODAF 
viewpoint form, enabling an informed and precise architecting effort. DODAF products 
can now be developed in compliance with enterprise processes while interacting with the 
warfighter in doctrinal/natural terms. This blended approach fosters the collaborative 
development environment necessary to expedite solution development. 
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V. CONCLUSION 


A. SUMMARY 

The DoD plans and executes operations when called upon, not necessarily 
synchronized with capability development schedules. Typically, to meet mission 
requirements, existing capabilities (personnel and equipment) are assembled from across 
the enterprise into a joint force that operates in a complex and uncertain environment. 
These time-sensitive joint operations are often missions that are other than combat. The 
capacity and multi-domain capability of the DoD is often called upon to support other 
government agencies and nations with humanitarian aid, emergency evacuation, and 
disaster relief missions. 

Both materiel (SoS/systems) and knowledge based capabilities (i.e., doctrine, 
training, lessons learned, and education) are required for all joint mission types. The DoD 
enterprise has three systems for developing these capabilities. Two of the three systems are 
focused on materiel development. Acquisition programs typically managed by the 
individual Services apply systems engineering methodologies as required by both statute 
and policy. Systems engineering for DoD, includes an enterprise architecture framework 
(DODAF) tool. The architecture products are required to support acquisition program 
decisions and improve interoperability. 

Joint warfighting capability is delivered through a knowledge based capability 
system, using a life cycle methodology, focused on the cognitive capabilities of the joint 
force. The state of knowledge, at a particular point in time, may be used to inform material 
capability decisions, but the life cycle is not synchronized with those schedules. Also, the 
primary requirements for materiel development are for combat capability, where joint 
warfighting capability spans all mission types and operating domains. 

The DoD recognizes three levels of warfare; strategic, operational, and tactical. 
Material development programs are typically focused at the tactical level (employment of 
forces) with operational context described by DODAF OV’s. These systems, developed 


107 



from a tactical perspective are organized into SoS architectures in order to realize 
additional capability. 

However, the DoD operates as a joint force, across all three levels of warfare. At 
the operational level of war, where the focus is on the cognitive approach to mission 
execution, a Joint Task Force will be organized. In compliance with authoritative guidance, 
commanders and staffs use operational art to plan, execute, organize, design, integrate, and 
assess these joint missions. From a joint warfighting perspective, operational level 
capability is therefore knowledge based, and not SoS based. However, operational mission 
success is certainly dependent on employed systems both achieving tactical effectiveness 
and supporting joint commanders’ and staffs’ decision-making. 

This joint knowledge resides in a plethora of documents, products, people, and 
locations managed through the JFD Life Cycle. Problems with this system’s ability to 
deliver timely knowledge based capability to both the operational force and system 
developers have been consistently identified. Likewise, architecture and design decisions 
during system development have introduced problems at the operational level. 

The DoD as an enterprise, needs to deliver joint warfighting capability when 
needed, not as development schedules dictate. Applying systems engineering 
methodologies at the operational level of war, in a complimentary manner to existing 
development systems, enables an efficient approach to delivering episodic enterprise 
systems for joint warfighting. 

Consistent with systems engineering best practices, a top-down approach is enabled 
by defining an architecture framework at the operational level. Pertinent information was 
identified and extracted from the multitude of joint warfighting documents and organized 
into a doctrinally consistent architecture framework composed of ten elements. The OMAF 
design reflects the hierarchical culture (commander focus at the top, followed by principal 
staff activities, and tactical SoS capability at the bottom). Systems engineers can now 
architect, design, and develop capability directly at the operational level, collaboratively 
with the joint warfighting community. 
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The concept and value of operational systems engineering was explored by the 
National Academy of Engineering and the USIP. The systems engineering methodology 
included a decision-making framework and the application of systems dynamics modeling. 
The influence of both context and guiding principles on mission execution was recognized. 
The systems engineering of multi-mission, multi-domain capability of the DoD enterprise 
requires a comprehensive architectural framework that goes beyond the mission decision¬ 
making element of joint operations. Architecting must be an activity conducted in the 
systems engineering effort. OMAF/OBAM delivers the all-inclusive architecture 
framework for DoD, facilitating the architecting element of systems engineering using 
enterprise tools and processes. Additionally, OMAF/OBAM delivers an operational 
mission reference architecture that enables the necessary top-down approach for MIM/ME 
implementation. 

Another exploration of systems engineering applications at the operational level 
was discovered in the literature search. Sitton and Reich recognized that ESE, SoS, and SE 
approaches did not address the asynchronous need for operational capability and referenced 
the need for an operational architecture framework. However, a framework was not defined 
or developed. They also proposed a different view of operational systems as “systems of 
arrays of systems (SAS).” (Sitton and Reich 2015). The OMAF/OBAM approach is more 
direct, introducing a new class of systems characterized by the desired attributes (temporal, 
transitional, asynchronous, and multi-mission) rather than a new arrangement for the 
enterprise to manage. Additionally, OMAF/OBAM defines the operational architectural 
framework and advances implementation by enabling the use of existing enterprise tools, 
authorities, and processes through integration. 

Case studies of DoD joint missions identified operational issues across mission 
types. An enterprise approach to delivering the necessary capability has not been 
developed. During the literature search, only a few examples of systems engineering 
approaches for operational capability were discovered. Neither included a comprehensive 
architecture or enterprise strategy to deliver. 

The OMAF/OBAM concept transforms the knowledge based joint warfighting 

capability into an architectural framework, enabling the application of systems engineering 
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beyond traditional material development. Episodic operational capability can then be 
realized by integrating the DoD capability development systems at the architectural level, 
delivering a new class of systems: episodic enterprise systems. 

This blended approach is unique. It leverages existing tools, authorities, and 
processes to create a collaborative enterprise approach. OMAF/OBAM enables precision 
architecting of temporal, transitional, asynchronous, and multi-mission capability not 
achievable through existing systems engineering methodologies. 

B. CONCLUSIONS 

The joint force continues to encounter operational capability challenges, across a 
variety of missions. Obstacles have been attributed to each of the DoD development 
systems (JFD and JCIDS/DAS) indicating that required capability cannot be developed by 
one system or the other. Therefore, joint mission capability must be developed, advanced, 
and sustained through an enterprise approach. However, neither capability development 
system is exclusively able to respond to the time sensitive, multi-mission nature of joint 
operations. A comprehensive effort is required. 

Furthermore, existing systems engineering methodologies (ESE, SOS, SE) do not 
address the operational level of the enterprise. Recall that the National Academy for 
Engineering and USIP for example, together explored the concept of “operational systems 
engineering” while, Sitton and Reich proposed a new arrangement (SAS) as well as the 
need for an enterprise operational architecture. 

The DoD’s proposed implementation of MIM moves the enterprise toward the 
systems engineering of operational mission capability through ME. However, the ME focus 
is still at the tactical level of warfare and SoS architectures. Without an operational mission 
architecture, and an approach to bridge the engineering and operational communities, ME 
will not adequately meet the intent of MIM. 

The nature of joint operations requires episodic operational capability. Through this 
research, the enterprise’s knowledge based approach was analyzed, distilled down, and 
organized into architecture form. OMAF transformed operational level capability from a 
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narrative form into a structured form, enabling the application of systems engineering 
methods and tools to resolve operational issues and develop episodic enterprise systems. 
This new class of systems is characterized by their temporal, transitional, asynchronous, 
and multi-mission attributes that drive design. Beyond the DoD, the notion of episodic 
capability applies to all enterprises. An ability to address unique challenges utilizing 
existing enterprise systems, processes, and relationships to achieve desired outcomes 
extends to all enterprises seeking to remain relevant in a rapidly changing 21st century 
technology landscape. 

The challenges associated with designing episodic operational capability are 
mitigated by leveraging existing enterprise architecture tools and processes. The standup 
of another capability development system to meet the time sensitive nature of joint 
missions is both unnecessary and too disruptive to the DoD bureaucracy. By characterizing 
OMAF elements in terms of the standard interrogatives, the appropriate DODAF 
viewpoints could be identified. The resultant map of operational elements and DODAF 
viewpoints blends the warfighting lexicon with systems engineering at the architectural 
level. OBAM creates the necessary collaborative environment for precision systems 
engineering and efficient multi-mission capability development. 

A variety of mission types was analyzed. Observations/issues were readily 
associated with OMAF elements and subsequently transformed to DODAF viewpoints 
through OBAM. The breadth and effectiveness of the OMAF design and architectural 
approach has been demonstrated. Also, the instantiation of mission issues as DODAF 
viewpoints, demonstrates the integrating function of OBAM. DoD enterprise architecture 
tools can indeed be employed to develop operational capability. 

Through this endeavor, enterprise operational capability has been defined 

architecturally, the concept of episodic enterprise systems introduced, and the integrating 

function to create an enterprise architecture for joint warfighting capability has been 

presented. Additionally, systems engineers are now positioned to participate in enterprise 

activities beyond the traditional development of systems-based capabilities. For example, 

in addition to the application of the OMAF methodology, systems dynamics modeling can 

also contribute to operations and contingency planning. Furthermore, systems engineers 
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can now contribute directly to improving knowledge-based capability. MBSE techniques 
can also be applied to both concept development and doctrine development, as well as to 
provide mission insight to joint operations by incorporating prospective lessons learned. 

Given the interdependencies of the disparate development systems, the history of 
issues exhibited at the operational level of war, and an increasingly complex and uncertain 
operational environment, status quo is not acceptable for DoD. A comprehensive 
multidisciplinary (i.e., systems engineering) approach that delivers episodic operational 
capability is urgently needed to deliver 21st century joint warfighting capability. By 
implementing OMAF/OBAM, the DoD can leverage enterprise strengths and help to 
deliver unity of effort for our warfighters. 

C. FUTURE RESEARCH 

The DoD recognizes and prepares for three levels of warfare (strategic, operational, 
tactical). Through this endeavor, an architectural representation and blended development 
approach (OMAF/OBAM) for the operational level was developed in order to engage 
systems engineers at the joint warfighting nexus. Further research is necessary to fully 
implement OMAF/OBAM and deliver episodic operational capability: 

1. Define and implement a “top-down” episodic enterprise systems 
engineering methodology. 

2. Develop reference operational mission architectures. 

3. Explore design approaches for desired episodic system attributes. 

4. Develop DODAF database management capability to include the 
operational level 

5. Develop DODAF database design enhancements to include the operational 
level. 

6. Explore the application of MBSE to identify “prospective lessons 
learned.” 


112 



7. Explore the application of behavioral modeling to the OMAF Elements. 

8. Explore the application of systems dynamics modeling to operational 
missions. 

9. Extend OMAF/OBAM to the strategic level of war. 
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